Pavel Machek wrote: > > > IMHO; no bug or security issue, just a misunderstanding of the > > mechanism... Correct. It is a completely flawed assumption. In Unix, an open() of a file checks access permissions as specified in the files inode. If someone wants access control applied to a file, then he MUST do so using the permission in the file inode. Making assumptions about directory search and acces permissions is plain stupid. > > The /proc/self/fd/X appears to be a symlink, but it is not; it > operates on underlying objects directly. And IMNSHO it should honor > restrictions opened filedescriptors have, like append-only or > read-only. /proc/self/fd/X is something virtual, not something real. It is state as held by the kernel, it is not persisted anywhere. The reason why it is visualized like a symlink is to provide clue about the actual filename behind that filedescriptor (at least at the time when the open was performed). If it was a real symlink, then it would no longer work if the file was renamed, moved to a different directory or deleted (while still open) between the creation of the file descriptor and the time that someone wanted to access the very same file through /proc. There are two conceivable approaches to implementing the open() for a filedescriptor shown in /proc. Either go throuh the inode and check the access permissions on the file at the current time (which is a sensible implementation and what the kernel seems to be currently doing), or implement it as a dup() and transfer of the filedescriptor. (Tranfering open filedescriptors between processes can also be done by IPC). Implemetenting it via dup() would probably keep the original filedescriptor attributes (such as read-only) but would require an entirely seperate approach to access control (who is allowed to dup() that filedescriptor), and it would create problems: like you would not be able to look into files that were opened only for write through /proc, which would seriously impair the usefulness of the fd-listing in /proc. This feature of /proc is just fine as it is. It does seem to confuse people who think in contorted fashion and make a lot of flawed assumptions, though (those guys are going to create many other security problems as well, so we should rather educate them about avoiding flawed assumptions. Directory access permissions are purely about access to directory contents (which are plain names), Directory access permissions (at least on Unix) do NOT affect access to files, and they're NOT checked for permission on open(2) -- and have never been. There may be a side-effect of directory access permissions when open(2) resolves a filename, but that is purely a side-effect, not a by-design feature guaranteed by open(2). Thinking otherwise is a flawed assumption. If you move (mv,rename) a file around in the filesystem, like from a 0700 directory into a 0755 directory, that operation will _not_ affect the file access permissions in the inode. It doesn't matter wether you did not intend the file to become available when you did the mv/rename. The OS will only check the file access permissions on the inode on open, and mv/rename doesn't touch them. Different path accessibility in the new location/directory is a pure side-effect, not a by-design feature of open(2) that any operations like "mv/rename" will guarantee. If you put world-writable (0666) access permissions on a file, the observed result is exactly what you asked for when doing so. Why does a file in a 0700 directory need anything more than 0600 access permissions as far as applications are concerned? The files inode does NOT know and NOT care where the directory entries are located that reference this inode and what permissions are on the directory and path up to the root. The real fun with unexpected results is with Microsoft Windows ACLs and inheritable permissions on directories. If you move files around there, the effects on the resulting access permissions of a file are quite often surprising, especially if the files are moved across device boundaries. There absolutely is not substitute for careful application design, If the observed behaviour with the linux fd-semantics in the /proc filesystem is a problem for an application, then this is a severe design flaw of the application, based on fatally flawed assumptions, not a security problem or vulnerability of the underlying OS. -Martin
