Re: /proc filesystem allows bypassing directory permissions on Linux

[Glynn Clements <glynn () gclements plus com>]

psz () maths usyd edu au 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 () gclements plus com>