Re: /proc filesystem allows bypassing directory permissions on Linux

[Derek Martin <code () pizzashack org>]

On Mon, Oct 26, 2009 at 07:37:38PM +0100, Ansgar Wiechers wrote:
> On 2009-10-24 Derek Martin wrote:
> > 1. It circumvents the fact that to write to a file, you MUST be able
> > to write to its directory, so that the file attributes can be updated.
>
> Wrong, because the file's attributes aren't stored in the directory, but
> in the respective inode.

Ah, sorry, you're right, but if (as in the example) the user has no
permissions on the directory, he normally won't be able to write to
the file:

$ mkdir foo
$ cd foo
$ echo hi > bar
$ ls -la
total 12
drwxr-xr-x  2 user1 group1 4096 2009-10-27 16:22 ./
drwx------ 57 user1 group1 4096 2009-10-27 16:22 ../
-rw-r--r--  1 user1 group1    3 2009-10-27 16:22 bar
$ chmod 000 .
$ echo bye > bar
-bash: bar: Permission denied

The problem with the /proc interface is:

 - it is automatic (if /proc is mounted)
 - its file access semantics are not identical to the rest of the file system
   (e.g. they are not really symlinks, and they are not really hard
   links, and the link count is not incremented, and the average
   person will have no idea about their semantics).
 - it creates a pseudo-link with permissions which do not regard the directory
   access controls the user had to pass authorization checks to gain access.

I still think it's not a huge deal, but I also do think it's not a
total non-issue.  The fix seems clear and obvious to me:  The files in
/proc/$pid are shown with the "real" path they refer to, so obviously
the kernel retains that information.  Access to those files should be
checked against that real path, rather than the /proc/$pid path.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

Attachment: _bin
Description: