On Sat, 28 Oct 2000, Stephen C. Tweedie wrote:
> 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.
Oh.
> 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.
So what you're saying is each user and group that is ever referred to in a
Posix ACL always has an id associated with it. The machine would just do
some remapping, similar to ugidd.
In that case I fail to see the original problem, as each Posix ACL can
already be represented using the format that I'm using in the kernel
(<linux/posix_acl.h>:posix_acl_t) right now.
> > 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.
>
> 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.
IMHO there isn't really such a thing as NFSv4 ACLs. There are SMBFS ACLs,
AFS ACLs, Posix ACLs, but no NTFSv4 ACLs. NFSv4 just provides a common
format for representing different variants of ACLs, but no semantics. So a
Posix ACL still stays a Posix ACL even if represented in NTFSv4 format. So
does an SMBFS ACL, etc.
(I'm _not_ saying this to annoy you, I'm just trying to nail down a few
things to eliminate further misunderstandings.)
When an NFSv4 request to set/retrieve a Posix ACL arrives, the
"[EMAIL PROTECTED]" identifiers can be translated into uid's/gid's. From
that point on, the data structures defined in include/linux/posix_acl.h in
my patch are perfectly suitable already.
If such a request arrives in userspace, then the "[EMAIL PROTECTED]"
identifiers can be translated into the respective id's before passing the
beast to the kernel. No problem here, either.
If your vision is to design a super ACL system for Linux that covers all
ACL implementations out there, then I'm afraid my opinion is that such an
attempt is in vein. Try to unify Posix 1003.1e ACLs and SMBFS (NT) ACLs.
It's hopeless. The result would be so complex it wouldn't be usable by the
average sysadmin anymore.
The ACL patch limits itself to support Posix 1003.1e draft standard 17
ACLs; nothing more and nothing less. I'm aware that there are many
features that would be nice to have. This is all possible in the future,
but extending the set of permissions supported is extremely brittle. The
people in the 1003.1e working group were no fools. I'd prefer not to add
anything to the framework lightly.
> > 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?
No, _of course_ not. I'm pretty sure the current interface is also
appropriate for XFS. If not, I'd like to know what the problems are as
soon as possible.
_Are_ there any concerns from the XFS camp?
> _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!
So do you think that passing uid's and gid's in the syscalls is the
problem?
Do you think the EA format I'm using for ACLs is inappropriate / too
restrictive?
Do you think that a flattened format is inappropriate?
Where exactly is the problem?
My idea was to use the extended attribute representation for passing ACLs
between userspace and the kernel. Of course, using a different and
functionally equivalent format is also possible, but I didn't see an
advantage in doing so. I have no real problem with using a different
format, provided that there are good reasons for it.
I don't think it makes sense to use a super format similar to the NFSv4
format for passing ACLs between the kernel and user space, though. The
kernel would have to translate "[EMAIL PROTECTED]" identifiers back into
id's anyway. This can more easily be accomplished in user space in the
first place. The id's can then be passed to the kernel directly.
Except for the "[EMAIL PROTECTED]" issue, which I believe is better dealt
with in userspace whenever possible, the format currently used is mostly
identical to the NFSv4 format: an array of ACL entries. Two of the bit
fields are only half the width, and the constants used are different, but
that's it.
The only remaining issue I see are remote mounted filesystems. For _those_
the other kind of identifiers is needed: NFSv4 servers would need
"[EMAIL PROTECTED]" identifiers; SMBFS servers would perhaps need NT SIDs
or similar. I think for those cases a separate interface that accepts
those identifiers makes sense.
For NFS, a much simpler approach than going through the kernel would be to
do a simple NFS RPC from userspace. I'm not 100% sure which problems this
might cause for security, but the kernel isn't strictly required here I
think.
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]
