On Sat, 28 Oct 2000, Stephen C. Tweedie wrote:
[Original message heavily edited.]
> 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?
Yes.
I meant the server machine does some sort of remapping from names to id's,
and I thought about how a Linux NFS server would do that. Surely the
network protocol is unaffected by that, and the client is totally isolated
from such details.
> [...]
> > 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.
What happens with users the client machine doesn't know about for things
like the file owner? What should system calls like stat(2) return? How
about chown(2)? ACL's aren't the only problem here.
Another idea: Does the _client_ machine know a mapping from id's to names
for its own part of the namespace, possibly with id's distinct from the
id's used on the server (remote users from a different realm surely are
not)?
If so, then the client's kernel could map these id's to the proper names
when needed, right?
It would then be completely transparent to applications running on the
client machine which kinds of id's are used on the wire for remote mounted
filesystems. Traversing filesystem mount points would be transparent, too.
ACLs could be set across different types of remote filesystems (provided
that the ACL systems supported are compatible, which is sort of
hypothetical at the moment).
On the other hand, it wouldn't be possible to grant permissions to users
from different realms through that mechanism...
> [...]
> > 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.
Ald you are right again. That't what comes from skimming parts of
specification. My apologies.
NFSv4 indeed specifies yet another variant of ACLs.
> [...]
> > 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.
I meant something like a userspace NFS daemon on the server machine. That
daemon could.
> [...]
> 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?
XFS also supports Posix 1003.1e ACLs, so the interface to XFS ACLs and
ext2 ACLs hopefully will be identical. NFSv4 and AFS have different
requirements.
> > 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?
Not a good idea, I admit.
Thanks,
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]
