From: Kyle Moffett <mrmacman_g4@mac.com>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Michael Tharp <gxti@partiallystapled.com>,
alan <alan@clueserver.org>, Marc Perkel <mperkel@yahoo.com>,
LKML Kernel <linux-kernel@vger.kernel.org>,
Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Subject: Re: Thinking outside the box on file systems
Date: Wed, 15 Aug 2007 13:53:53 -0400 [thread overview]
Message-ID: <DE34FF90-3143-4978-BBC5-3CF74B8C3C07@mac.com> (raw)
In-Reply-To: <46C33934.7060802@cfl.rr.com>
On Aug 15, 2007, at 13:34:44, Phillip Susi wrote:
> The problem that I have with this setup is that it specifies an ACL
> on EACH file. Yes, you can set a default on the directory for
> newly created files, but what if I want to add a user to the access
> list for that whole directory? I have to individually update every
> acl on every file in that directory.
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.
> Also if you move a file created elsewhere into that directory, it
> retains its existing permissions doesn't it?
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?
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?
> I would rather just add a new ace to the directory itself which
> specifies that it applies to the entire tree. Then you only need
> to store a single acl on disk, and only have to update one acl to
> add a new user.
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.
Cheers,
Kyle Moffett
next prev parent reply other threads:[~2007-08-15 17:54 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-14 22:45 Marc Perkel
2007-08-14 22:51 ` alan
2007-08-15 13:02 ` Michael Tharp
2007-08-15 13:30 ` Lennart Sorensen
2007-08-15 13:53 ` Kyle Moffett
2007-08-15 15:14 ` Michael Tharp
2007-08-15 16:36 ` Marc Perkel
2007-08-15 17:17 ` Kyle Moffett
2007-08-15 17:30 ` Marc Perkel
2007-08-15 18:22 ` Craig Ruff
2007-08-15 20:35 ` Marc Perkel
2007-08-16 11:27 ` Helge Hafting
2007-08-15 16:02 ` Marc Perkel
2007-08-15 16:57 ` Valdis.Kletnieks
2007-08-15 17:09 ` Marc Perkel
2007-08-15 17:22 ` Kyle Moffett
2007-08-15 17:34 ` Marc Perkel
2007-08-18 23:27 ` Alan
2007-08-18 23:26 ` Alan
2007-08-19 2:03 ` david
2007-08-19 2:57 ` Al Viro
2007-09-01 23:20 ` Oleg Verych
2007-08-15 19:20 ` Lennart Sorensen
2007-08-16 23:12 ` H. Peter Anvin
2007-08-15 16:58 ` Kyle Moffett
2007-08-15 17:19 ` Marc Perkel
2007-08-15 17:37 ` Kyle Moffett
2007-08-15 17:59 ` Marc Perkel
2007-08-15 19:26 ` Lennart Sorensen
2007-08-15 20:11 ` Kyle Moffett
2007-08-15 20:44 ` Marc Perkel
2007-08-15 21:04 ` Lennart Sorensen
2007-08-16 11:42 ` Helge Hafting
2007-08-16 12:09 ` linux-os (Dick Johnson)
2007-08-15 17:34 ` Phillip Susi
2007-08-15 17:53 ` Kyle Moffett [this message]
2007-08-15 18:05 ` Marc Perkel
2007-08-15 18:14 ` Kyle Moffett
2007-08-15 20:20 ` Marc Perkel
2007-08-15 20:43 ` Phillip Susi
2007-08-15 20:50 ` Marc Perkel
2007-08-15 21:20 ` Valdis.Kletnieks
2007-08-15 22:48 ` Marc Perkel
2007-08-16 3:42 ` Valdis.Kletnieks
2007-08-15 20:38 ` Phillip Susi
2007-08-15 21:17 ` Kyle Moffett
2007-08-15 22:14 ` Phillip Susi
2007-08-16 4:44 ` Kyle Moffett
2007-08-16 15:09 ` Phillip Susi
2007-08-16 15:29 ` Valdis.Kletnieks
2007-08-16 17:28 ` Phillip Susi
2007-08-16 17:31 ` Valdis.Kletnieks
2007-08-16 22:03 ` Phillip Susi
2007-08-16 23:17 ` Kyle Moffett
2007-08-17 4:24 ` Marc Perkel
2007-08-17 4:52 ` Valdis.Kletnieks
2007-08-17 15:19 ` Phillip Susi
2007-08-17 15:39 ` Valdis.Kletnieks
2007-08-17 19:01 ` Phillip Susi
2007-08-18 5:48 ` Kyle Moffett
2007-08-18 16:45 ` Marc Perkel
2007-08-18 18:19 ` Al Viro
2007-08-19 4:07 ` Marc Perkel
2007-08-20 7:05 ` Nix
2007-08-20 7:47 ` Brennan Ashton
2007-08-20 11:18 ` Marc Perkel
2007-08-20 13:32 ` linux-os (Dick Johnson)
2007-08-20 15:25 ` Lennart Sorensen
2007-08-20 15:26 ` Helge Hafting
2007-08-20 19:52 ` Nix
2007-08-20 16:21 ` [OT] " Randy Dunlap
2007-08-20 16:20 ` Xavier Bestel
2007-08-20 14:29 ` Phillip Susi
2007-08-20 15:13 ` Lennart Sorensen
2007-08-20 14:24 ` Phillip Susi
2007-08-15 22:40 ` Marc Perkel
2007-08-15 17:54 ` Marc Perkel
2007-08-15 17:02 ` Marc Perkel
2007-08-15 17:30 ` Michael Tharp
2007-08-15 17:51 ` Marc Perkel
2007-08-15 20:02 ` Yakov Lerner
2007-08-15 7:49 Tim Tassonis
2007-08-15 18:23 Brian Wheeler
2007-08-20 11:54 Tim Tassonis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DE34FF90-3143-4978-BBC5-3CF74B8C3C07@mac.com \
--to=mrmacman_g4@mac.com \
--cc=alan@clueserver.org \
--cc=gxti@partiallystapled.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=mperkel@yahoo.com \
--cc=psusi@cfl.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®