> >pavel@toy:/tmp/my_priv$ chmod 700 . > ># relax file permissions, directory is private, so this is safe > ># check link count on unwritable_file. We would not want someone > ># to have a hard link to work around our permissions, would we? > >pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file > >pavel@toy:/tmp/my_priv$ cat unwritable_file > >this file should never be writable > >pavel@toy:/tmp/my_priv$ cat unwritable_file > >got you > ># Security problem here > > > >[Please pause here for a while before reading how guest did it.] ... > ># Linux correctly prevents guest from writing to that file > >guest@toy:/tmp/my_priv$ cat unwritable_file > >cat: unwritable_file: Permission denied > >guest@toy:/tmp/my_priv$ echo got you>&3 > >bash: echo: write error: Bad file descriptor > > > ># ...until we take a way around it with /proc filesystem. Oops. > >guest@toy:/tmp/my_priv$ echo got you> /proc/self/fd/3 > > > That can hardly be called a real security hole, since the behaviour > described above is expected, and is as it was conceived by design. > If the file owner in fact allows writing to it, why should Linux > prevent that from happening? No, I do not think this is expected. You could not write to that file under traditional unix, and you can not write into that file when /proc is unmounted. I do not think mounting /proc should change access control semantics. Plus, you may run traditional unix/POSIX application, expecting directory access controls to prevent the write. (Or can you see a way to write to that file when /proc is unmounted?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
