3 ms·
Hm, from what I can tell this doesn't seem to be possible. There is one way to open a directory without read permissions, which is with O_PATH, but the resulti
by ekimekim 6y ago
Hm, from what I can tell this doesn't seem to be possible.
There is one way to open a directory without read permissions, which is with O_PATH, but the resulting fd can only be used "to indicate a location in the filesystem tree and to perform operations that act purely at the file descriptor level". And indeed if you try to use this fd to fsync() you get EBADF.
I guess this is just an edge case of an edge case that most people aren't concerned about. One way to work around this issue with a bare minimum of compromise to security would be a setuid program that does nothing but open its working directory then fsync it.
- nh2 6y agoPrograms that care about durability should use `openat(int dirfd, char *pathname, ...)` to get an FD on the file after after getting an FD on the parent dir anyway, instead of using `/path/to/dir/file` style paths, because otherwise there's always the chance that something in hierarchy was moved away or mounted over. In that case, you always have a handle on the directory. Opening the dir for fsyncing separately after having written the file is similar to doing close()+re-open()+fsync() on a file, which does not provide as strong guarantees as direct open()+fsync(): https://stackoverflow.com/questions/37288453/calling-fsync2-after-close2/50158433#50158433 https://stackoverflow.com/questions/37288453/calling-fsync2-...