On Tue 2009-10-27 21:19:19, Marco Verschuur wrote: > My buy.. :-( I persumed a re-use of the read-only FD, but that's not > the case. > > I replayed it on a test-box and did some strace meanwhile and also > took a look > at the sourcecode of kernel/fs/proc. > > It seems that the /proc filedescriptor is directly referring the > file inode > When creating this proc-entry the user guest did have access to the > file and the path via tmp, > therefore a successfull filedescriptor straight to the file inode is > being created, while checking > th entire path towards the file. > > Although closing the path to the file, the actual file is made world > writable due to the file permissions being 666. > When guest does the "echo got you > /proc/self/fd/3" the /proc > filedescriptor (which directly refers the file inode) > is opened in O_WRONLY. So user guest is able to write the file. > IMHO; no bug or security issue, just a misunderstanding of the > mechanism... Well, existing unix mechanisms would not allow writing to that file. So yes, it works as authors intended, but I believe it is misdesigned and security problem. 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. (Or alternatively, it could be fixed to behave like real symlinks. But that would break /proc/*/fd/ on deleted files). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
