On Sat, 28 Oct 2000, Daniel Phillips wrote:
> "Stephen C. Tweedie" wrote:
> > On Fri, Oct 27, 2000 at 10:46:26AM +0200, Andreas Gruenbacher wrote:
> > > Imagine if the kernel did store
> > > "[EMAIL PROTECTED]" on ACLs on the filesystem. When an access control
> > > decision needs to be done, the kernel simply has no idea about what
> > > "[EMAIL PROTECTED]" means.
> >
> > The VFS doesn't, but the filesystem does. In NFSv4, what happens at
> > the moment is that the kernel says "I don't know who the local user
> > is" and asks a local GSS daemon to do a kerberos authentication on the
> > user. Once that is complete, both the client and the server have an
> > authenticated and secure ID for the user of the form "username@REALM".
>
> Since we have 32 bits worth of UID and GID now, why can't we create a
> temporary UID at this point? Each unique ACL would be assigned a unique
> GID and the temporary UID would belong to some appropriate set of
> groups. This is such an obvious idea that I assume it must have been
> discussed and rejected, but why?
I guess I meanwhile understand the purpose of "[EMAIL PROTECTED]"
identifiers (thanks Stephen, that was something I badly needed to catch up
with). The point seems to be not to have to mangle all user/group
identifiers into integers. A single uid/gid based user database doesn't
scale up to the size of the Internet.
"u@d" identifiers are passed in NFS requests to the NFS server. The server
verifies the authenticity of the request and identity, and uses the "u@d"
identifier directly to decide whether access is granted or not. In ACLs on
the filesystem, the same "u@d" identifiers are stored and compared against
the requests.
Translating all "u@d" identifiers into uid's/gid's would bring back the
same scalability problems the approach tries to get rid of.
I have my serious doubts how this could be implemented efficiently over
today's filesystems, though.
On plain-old ext2, uid's/gid's are used to identify file owners and owning
groups. What would one do with these id's in combination with "u@d"
identifiers? Some mechanism to translate from numeric id's to "u@d"
identifiers would be needed, but that's not possible entirely within the
kernel. Interactions with userspace daemons are slow and much less secure
than in-kernel mechanisms.
Also, do you store all identifiers known locally by id? How would changes
to the local user database affect the filesystem? Do you store both "u@d"
and uid's for all files? How about conflicts between namespaces? You would
also need to store the "u@d" and "g@d" identifiers of a file's owner and
owning group. (EA's seem a good mechanism for storing such complementary
information, but that observation is by far not enough to make it work.)
Which ACL semantics should NFS supporting ACLs implement? Should this be
Posix 1003.1e ACLs? The NFS protocol supports virtually all variants of
ACLs, but doesn't specify any semantics.
How do you ensure filesystem access checks are still blazingly fast?
Remember, for opening a file all the permissions along the path leading to
that file need to be checked. String comparisons ("u@g") seem quite
problematic.
These are simply too many questions for a straightforward implementation.
So I tend to think we should as a first step try to get plain Posix
1003.1e ACL's into the mainstream kernel without all those extensions, and
try to gain some more experience. That alone would bring Linux much closer
to large scale / trusted operating system. Paired with filesystem
capabilities support, Linux would get much "sexier", and more serious as
well.
Meanwhile, somebody will probably come along with many answers to the
other scalability problem. Of course, we could try to come up with the
perfect system first, and realize that later. That's surely not the most
effective approach IMHO.
Comments welcome, of course...
Cheers,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
