Bugtraq mailing list archives
Re: /proc filesystem allows bypassing directory permissions on
From: Martin Rex <Martin.Rex () sap com>
Date: Tue, 3 Nov 2009 00:33:28 +0100 (MET)
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
Current thread:
- Re: /proc filesystem allows bypassing directory permissions on Martin Rex (Nov 02)
- Re: /proc filesystem allows bypassing directory permissions on Pavel Machek (Nov 02)
- Re: /proc filesystem allows bypassing directory permissions on Gabor Gombas (Nov 03)
- Re: /proc filesystem allows bypassing directory permissions on Martin Rex (Nov 03)
- Re: /proc filesystem allows bypassing directory permissions on Gabor Gombas (Nov 03)
- Re: /proc filesystem allows bypassing directory permissions on psz (Nov 04)
- Re: /proc filesystem allows bypassing directory permissions on Gabor Gombas (Nov 04)
- Re: /proc filesystem allows bypassing directory permissions on Pavel Machek (Nov 04)
- Re: /proc filesystem allows bypassing directory permissions on Pavel Machek (Nov 04)
- Re: /proc filesystem allows bypassing directory permissions on psz (Nov 04)
- Re: /proc filesystem allows bypassing directory permissions on Gabor Gombas (Nov 04)
- Re: /proc filesystem allows bypassing directory permissions on Gabor Gombas (Nov 03)
- Re: /proc filesystem allows bypassing directory permissions on Pavel Machek (Nov 02)
- Re: /proc filesystem allows bypassing directory permissions on Dan Yefimov (Nov 03)
- Re: /proc filesystem allows bypassing directory permissions on Pavel Kankovsky (Nov 05)