Figure out how to deal with inaccessible parent directories

[Stebalien]

So, unix really is lovely...

> mkdir -p /foo/bar
> cd /foo/bar
> chmod a-x /foo
> touch first
> touch /foo/bar/second
touch: cannot touch '/foo/bar/second': Permission denied

As written, this library has the same problem as the second case. We use the absolute path when creating temporary files instead of the relative path. I believe this can actually be an issue in practice with some jails.

Fixing this on linux is doable with openat and unlinkat. Fixing this on osx is possible using per-thread CWDs (at the cost of two extra syscalls to set/unset the thread-local CWD).

[tbu-]

According to What non-Linux Unixes support openat? from StackOverflow:

[…], all major BSDs and Apple's OS X seem to support [openat] as of today:

• DragonFly since DragonFly 2.3.
• FreeBSD since FreeBSD 8.0.
• Linux since Linux 2.6.16 (for completeness).
• NetBSD since NetBSD 7.0.
• OpenBSD since OpenBSD 5.0.
• OS X since OS X 10.10.
• Solaris.

[Stebalien]

Ah. The information I was looking at was from 2011. Good to know.

[rbtcollins]

fs_at is a new crate I created as part of fixing the TOCTOU remove_dir_all inherited from the std::fs::remove_dir_all it was based on years ago; it uses NTCreateFile on windows and openat on unix - my intent for it is to be a medium-level crate: no sophisticated features or policy choices, just convenient access to 'at' style syscalls. If its not suitable for solving this bug, I'd like to know why so I can fix it.

[Stebalien]

I'm tracking all 4.0 changes in #327.

[Stebalien]

Hm. Actually, I'm going to re-open this so we have a place to discuss it. To implement this:

1. TempPath, NamedTempFile, and TempDir would have to keep the parent directory open. However, even if we do that, I don't want to return relative paths when the user calls .path(). But if I return an absolute path, it'll probably break a good number of applications anyways.
2. tempfile() and SpooledTempFile would have to briefly open the parent directory when creating unnamed temporary files is impossible.

Maybe just implement the latter?

[nagisa]

Plenty of other ways in which a base directory name/path might start not working right:

1. Any component is a symbolic link that gets changed to something else;
2. mv dir dir2;
3. in addition to the chmods changing, acls changing are also a concern;

Holding the dirfd of an immediate parent handles most of these problems (with the chief problem of it being difficult to have a full-featured API that also supports windows in the same way). The only thing I'm not super sure of is whether unlinkat would continue working if between file creation and deletion the directory permissions change to disallow writes (testing, now I'm curious)

[nagisa]

A: yes, if the write permissions on the directory change while holding the dirfd you are prevented from deleting the file even with unlinkat. Test code:

use rustix::fs::*;

fn main() {
    let cwd = open(".", OFlags::DIRECTORY, Mode::empty()).unwrap();
    mkdirat(&cwd, "testdir", Mode::RWXU).expect("remove ./testdir before trying again");
    let dirfd = openat(&cwd, "testdir", OFlags::DIRECTORY, Mode::empty()).unwrap();
    let file = openat(&dirfd, "filename", OFlags::CREATE | OFlags::TRUNC | OFlags::WRONLY, Mode::RWXU).unwrap();
    fchmod(&dirfd, Mode::empty()).unwrap(); // same with `r-x` or `rw-`
    drop(file); // close
    unlinkat(&dirfd, "filename", AtFlags::empty()).unwrap(); // fails with PermissionDenied
}

But at least we wouldn't be deleting files in potentially wrong places altogether.

[Stebalien]

I think the remaining issues would be:

1. File is renamed within the directory. Not much I can do about that. I could check with /proc but I'm trying to avoid touching proc.
2. Directory (and file) permissions, as you say.

In terms of Windows support, I can actually delete files by handle (probably, there are some edge cases). I should switch to that anyways.

The main reason I haven't done this is that it'll cost another file descriptor, even in cases where the user might not expect it (e.g., TempDir. But I'll consider it for v4 (maybe with a way to opt-out program wide?).