Hi,
On Sat, Oct 28, 2000 at 09:13:23PM +0200, Andreas Gruenbacher wrote:
> On Sat, 28 Oct 2000, Stephen C. Tweedie wrote:
>
> > 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.
Huh? I already said that this is a SERVER-SIDE implementation detail
and has nothing at all to do with what is happening on the wire. The
ACL API on the client side is *completely* isolated from such details.
The on-the-wire protocol makes it totally impossible for the client to
know what is going on inside the server. See?
This is why I was saying that this is an irrelevant implementation
detail: it *CANNOT* have any bearing on the API exposed at the client
end for NFSv4 or AFS.
> 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.
Actually, NFSv4 defines interpretation order, inheritance rules,
default ACLs, directory and non-directory ACEs and all the other
semantics, perfectly unambiguously. NFSv4 ACLs do exist, I'm afraid.
> 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.
I keep trying to tell you that the implementation of ACLs on storage
is not the issue here --- the API at the client is. Sure, there are
any number of ways in which an NFS server might implement NFSv4 ACLs,
but that is (and has to be) completely transparent to the client on
which the ACL-setting API is being accessed.
> 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.
No they can't, because those ids are not present on the client.
> 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.
No --- my desire is to have one API which lets the application know,
unambiguously, which semantics are being granted even in the presence
of multiple implementations.
You seem to be saying that just because you have got a perfectly good
POSIX ACL implementation, all other implementations should be thrown
away and should have no impact on the API being selected. Well, I'm
afraid that all these other systems already exist, and we can't ignore
that.
I don't want to *unify* ACLs --- existing implementations which are
restricted by history to offering only certain forms of ACL will not
necessarily be able to be mapped onto each other. To try to do so
would be in vain. I _do_ want to have enough versioning information
in the API so that the application can set an NTFS ACL on an NTFS
filesystem and a POSIX ACL on an ext2 ACL-enabled filesystem. The
ACLs themselves remain distinct.
> 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.
And I've been saying all along that this is fine, but that your
implementation is only one of many that must be supported. We don't
have to support all at once --- we already have per-filesystem
permissions callbacks which allow individual filesystems to offer
whatever access policy they want. If other filesystems choose to add
ACL support to their permissions method, then the API must be able to
talk to those methods.
> 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.
I'm not talking about adding anything to the framework -- I'm talking
about recognising that other people have already implemented other
frameworks and that the kernel must be able to support them at the
same time. Obviously only one ACL implementation will be present per
filesystem, but you want to be able to have NFSv4, AFS, XFS and ext2
filesystems mounted at the same time, don't you?
> > 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.
Then take NFSv4 as a different example --- your interface is clearly
insufficient for that.
> > _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?
That's one part of the problem, yes.
> Do you think the EA format I'm using for ACLs is inappropriate / too
> restrictive?
Far too restrictive, and coupling ACLs to EAs is wrong: there already
exist filesystems which make no such coupling, and there already
exist filesystems which make the mapping differently, and there
already exist filesystems which may offer ACLs but not EAs.
> Where exactly is the problem?
1) You don't allow for credentials which are not uids or gids.
2) You don't allow for support for filesystems whose existing ACL
implementation is not POSIX.
3) You don't allow for additional types of ACE not contained in POSIX
(and there may be many --- eg. audit or alarm ACEs)
4) You make arbitrary exceptions to the EA interface to pretend that
ACLs are always EAs.
> 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.
There is an enormously good reason. Your API is fine if you happen to
have an impementation which encodes the ACL as the EA in question.
What happens on a filesystem which doesn't? You suddenly find that
you have to special-case what the filesystem considers to be a
perfectly normal, random EA request, have it pick out all of the
information in your POSIX request, map it into whatever the filesystem
happens to be able to provide, and finally reroute it down some
completely different internal API to set it. That's just ugly.
> 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.
Read my original proposal. It allowed you to use uids, but if you
happened to be passing utf/8, it gave you the ability to say so.
> Except for the "[EMAIL PROTECTED]" issue, which I believe is better dealt
> with in userspace whenever possible
It can't be dealt with in user space when you are setting ACLs on a
remote filesystem to grant or deny access to a third party in a
different realm.
> 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.
Exactly, and my API allowed you to do so by giving those filesystems a
different ACL family.
> 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.
Errm, sorry? You want unprivileged users doing security-related rpcs
themselves without kernel checking? You want user space poking bytes
down into the kernel's private tcp connection to the server?
And what if the kernel can already do this stuff (as it should)? You
want to avoid defining a clean API to that kernel functionality?
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
