Re: /proc filesystem allows bypassing directory permissions on

[Martin Rex <Martin.Rex@xxxxxxx>]

Gabor Gombas wrote:
> 
> On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
> 
> > > The link count of a files tells you the number of hard links that
> > > are persisted within the same filesystem.  It is _NOT_ a promise
> > > that there are no other means to access the inode of the file.
> > 
> > It used to be promise before /proc was mounted.

NOPE. There _NEVER_ was such a promise.

There may be flawed assumptions to that effect, but that doesn't
change history.

I couldn't find anything in the the POSIX 1003.1-2004 Online Edition
that _requires_ this to fail:

      int fd = open("/tmp/testfile", O_RDONLY);
      curmode = fcntl(fd,F_GETFD);
      curmode &= ~O_RDONLY;
      curmode |= O_RDWR;
      fcntl(fd,F_SETFD,curmode);
  
current AIX, HP-UX, Linux and Solaris seem to ignore that fcntl(F_SETFD)
for the access modes (read/write) entirely.


And the POSIX 1003.1-2004 Online Edition for fcntl(2) says
this in the RATIONALE:

  The arg values to F_GETFD, F_SETFD, F_GETFL, and F_SETFL all
  represent flag values to allow for future growth. Applications
  using these functions should do a read-modify-write operation
  on them, rather than assuming that only the values defined by
  this volume of IEEE Std 1003.1-2001 are valid. It is a common
  error to forget this, particularly in the case of F_SETFD.

Especially important: the last sentence!


Changing the access modes of a file descriptor is probably difficult
to implement.  It may be feasible for file in the filesystem which
has an inode with access permissions which could be checked.
Doing it for a socket might be a bad idea -- and usually impossible,
one cannot undo the shutdown(SHUT_WR) of a socket...


> 
> "mount --bind" behaves like a hard link and it does not increment the link
> count.

that seems to work similar to a hardlink on a directory (and also requires
root privileges).  It doesn't work for the same directory level, because
of this (the directory permissions of the mounted directories and
directories below it remain effective -- the permissions of directories
above disappear, however!

So yes, in a 2-level directory situation, the path permissions may also
disappear, voiding all flawed assumptions of an application about
path permission in an obvious way.

  /tmp/dir        0x700
  /tmp/dir/subdir 0x755
  /tmp/dir/subdir/secret_file_with_improper_permissions  0x666

if root has issued
mount --bind /tmp/dir/subdir /mnt
then secret_file_with_improper_permissions will be accessible
through an additonal path in the filesystem and this will not
be reflected in the inode link counts.


-Martin