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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
