psz@xxxxxxxxxxxxxxxxx wrote: > > According to POSIX, if you open the directory with O_SEARCH then openat() > > does not re-check search (+x) permissions. > > My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH. > But anyway... even if openat() does not re-check permissions, it should > surely fail when in fact it does not have permissions? Surely, directory > contents are not cached? Or, do you have an example (of a running OS) > where openat() succeeds without permissions? Linux 2.6.29.5 checks the directory permissions in openat(), but I can believe that other platforms (particularly those with an O_SEARCH flag) may not. For files, permissions are checked during open(); they don't get re-checked during subsequent operations on the returned descriptor. E.g. if you successfully open() a file O_RDWR, the permissions aren't re-checked for every read() and write(). If the permissions are removed, read() and write() won't suddenly fail (note that neither read() nor write() can fail with EPERM). open() checks that the user has the necessary privilege, then records that information in the descriptor for use by subsequent operations. For consistency, I would expect directory descriptors to behave similarly, i.e. open()ing a directory with O_SEARCH would check that the user has search (+x) permission on the directory then record this in the descriptor. A subsequent openat() would simply check the descriptor, not the inode. That Linux doesn't behave like this is an inconsistency, and is probably related to the lack of an O_SEARCH flag, i.e. descriptors only have flags for read and write permission, not directory search permission. AFAICT, there is no way to use open()+openat() for a directory with mode 0111 (d--x--x--x) as you can't open() the directory (O_RDONLY fails with EPERM, anything else fails with EISDIR). -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>
