Hi,
On Sat, Oct 28, 2000 at 05:17:11PM +0200, Andreas Gruenbacher wrote:
> On Sat, 28 Oct 2000, Daniel Phillips wrote:
> 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.
No, that misses the point. It's not about scaling as much as it is
about generalising credentials.
If you have a centralised storage server, you may have several
existing networks connect to that server and those networks may all
already have their own uid/gid namespaces (or, in fact, they may use a
totally different namespace such as NT SIDs). uid 777 on my network
might be a completely different user to uid 777 on your network, but
we might both want to share a storage server and I might want to grant
different access rights to the two separate users who happen to have
the same uids on their local systems.
> "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.
Not at all --- it is quite easy to believe that such a networked
storage server could easily represent all of its distributed users in
some private, local 32-bit uid/gid namespace internally. That's an
implementation detail. It is the communication between different
authentication realms which needs the extra abstraction, because the
local namespaces in each realm just don't mean anything in the other
realms.
> 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.
Sure, but we don't have any choice. NFSv4 mandates this mechanism,
and requires that we support Kerberos authentication, which as you
point out really ought to be done in user space. That is already
working in the NFSv4 code. The kernel doesn't have to know about any
other credentials scheme --- it just uses the same old uid/gid
combinations. However, the initial authentication pass between client
and server is done in user land at the kernel's request, and is done
using the Kerberos namespace.
> Also, do you store all identifiers known locally by id? How would changes
> to the local user database affect the filesystem?
Does it matter? Reusing uid/gids which already exist on the
filesystem is _already_ a security hole. Obviously this needs to be
addressed in user space, and obviously it's not a new problem.
> 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.
But all this is irrelevant --- these are implementation details. Most
filesystems won't want to care about this. Some will. If you want to
export NFSv4 filesystems, you _might_ just make an initial assumption
that anybody in the local domain gets a credential "uid@domain", and
any unrecognised domain gets mapped to "nobody". That's an
implementation detail which may make sense, but we cannot afford to
finalise the API assuming that only naive implementations will exist.
The question at hand is the API, not the implementation. We need an
API which lets us manage POSIX ACLs, and which also lets us manage
NFSv4 ACLs.
> 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.
We already have XFS working for Linux. XFS has an ACL implementation.
Are you saying we should start off by merging in an API which is
specifically tailored for an ext2-only implementation of POSIX-1003.1e
ACLs and which won't let XFS expose their ACL support to user space?
_This_ is what I am opposed to --- making the initial API closely tied
to one single implementation. We have an opportunity either to make
it easier for other filesystems to expose ACL support in a sane
manner, or to make it harder. I vote to make it easier!
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
