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:
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.
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.
>
> 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
[ reply ]