Message-ID: <46C3644C.9020102@cfl.rr.com>
Date:	Wed, 15 Aug 2007 16:38:36 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Kyle Moffett <mrmacman_g4@....com>
CC:	Michael Tharp <gxti@...tiallystapled.com>,
	alan <alan@...eserver.org>, Marc Perkel <mperkel@...oo.com>,
	LKML Kernel <linux-kernel@...r.kernel.org>,
	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Subject: Re: Thinking outside the box on file systems

Kyle Moffett wrote:
> We've *always* had to do this; that's what "chmod -R" or "setfacl -R" 
> are for :-D.  The major problem is that the locking and lookup overhead 
> gets really significant if you have to look at the entire directory tree 
> in order to determine the permissions for one single object.  I 
> definitely agree that we need better GUIs for managing file permissions, 
> but I don't see how you could modify the kernel in this case to do what 
> you want.

I am well aware of that, I'm simply saying that sucks.  Doing a 
recursive chmod or setfacl on a large directory tree is slow as all hell.

> So what would you have happen when you move another directory into that 
> directory?  Should it retain its permissions?  If they change based on 
> the new directory then do you recurse into each subdirectory?  Such 
> recursing to modify permissions also has significant performance 
> implications.  What about if the file is hardlinked elsewhere; do those 
> permissions change?

Simple... the file retains any acl it already had, AND the acl of the 
new directory now applies.  Most likely the moved file had no acl and 
was just inheriting its effective acl from its old parent directory. 
The end result is that people who used to have access to the file by 
virtue of it being in their directory no longer do, and the people who 
are supposed to have access to all files in the new directory get access 
to this one.

As for hard links, your access would depend on which name you use to 
access the file.  The file itself may still have an acl that grants or 
denies access to people no matter what name they use, but if it allows 
inheritance, then which name you access it by will modify the effective 
acl that it gets.

As for performance implications, I hardly think it is worrisome.  Each 
directory in the path has to be looked up anyhow so you already have 
their acls, so when you finally reach the file, you just have to take 
the union of the acls encountered on the way.  Should only be a few cpu 
cycles.

> There's also the question of what to do about namespaces and bind 
> mounts.  If I run "mount --bind /foo /home/foo", then do I get different 
> file permissions depending on what path I access the file by?  What if I 
> then run chroot("/foo"), do I get different file permissions then?  What 
> if I have two namespaces, each with their own root filesystem (say 
> "root1" and "root2"), and I mount the other namespace's root filesystem 
> in a subdir of each:
>   NS1:  mount /dev/root2 /otherns
>   NS2:  mount /dev/root1 /otherns
> 
> Now I have the following paths to the same file, do these get different 
> permissions or the same?
>   NS1:/foo == NS2:/otherns/foo
>   NS2:/bar == NS1:/otherns/bar
> 
> If you answered that they get different permissions, then how do you 
> handle the massive locking performance penalty due to the extra 
> lookups?  If you answered "same permissions", then how do you explain 
> the obvious discrepancy to the admin?

Good question.  I would say the bind mount should have a flag to 
specify.  That way the admin can choose where it should inherit from.  I 
also don't see where this locking penalty is.

> The idea is nice, but as soon as you add multiple namespaces, chroots, 
> or bind mounts the concept breaks down.  For security-sensitive things 
> like file permissions, you really do want determinate behavior 
> regardless of the path used to access the data.

How does it break down?  Chroots have absolutely no impact at all, and 
the bind mounts/namespaces can be handled as I mentioned above.  If you 
really want to be sure of the effective permissions on the file, then 
you simply flag it to not inherit from its parent or use an inherited 
rights mask to block the specific inherited permissions you want.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists