Hi,
On Sun, Oct 29, 2000 at 02:45:32PM +0100, Andreas Gruenbacher wrote:
> > > 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.
Of course. There are several different possible implementations. You
could restrict local processes to have the rights of a limited subset
of the possible utf/8 user strings, and map any other remote user
strings to the nobody id. chown is much easier --- the local machine
can easily decide on what mapping it uses from local uids to remote
utf/8 identifiers.
ACLs aren't the only problem, of course. But they are still a problem
we need to address.
> 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
Implementation detail --- most clients will indeed know such a
mapping, but they are not required to (in theory a client could
legally map all remote ids to the "nobody" user and use the
"ANONYMOUS@" pseudo-remote-id for all credentials checking).
> If so, then the client's kernel could map these id's to the proper names
> when needed, right?
Yes. Exactly. You're getting the point --- it is possible for a
client to manage the mapping for local uids in a sane manner, because
the protocol doesn't impose any semantics on the utf/8 name other than
the "id@domain" format. The local client can, if it chooses, use the
numeric local uid/gid for the "id" part in all of its mappings, or it
can use the username if there is a mechanism for obtaining that.
The same lack of semantics on the "id" part which allows local clients
to map their own local uid space any way they want, also prevents
local clients from doing any useful parsing of remote ids. For remote
ids, utf/8 is the only token available.
> 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).
Indeed.
> On the other hand, it wouldn't be possible to grant permissions to users
> from different realms through that mechanism...
Indeed. That's what I've been saying all along. The "name family"
part of the attribute API I proposed allows you to use local uids even
on the ATR_NFSV4ACL ACL family, so that the type of local uid-to-id
mapping you describe can be performed transparently even when we are
specifying NFSv4 ACL semantics. However, for setting remote ACL
rights, we still need to be able to specify ids in terms of utf/8 too.
My API deals with this. It lets you work purely in terms of uids
where the local implementation can deal with that, but also allows you
to grant rights to "foreign" users.
> > [...]
> > > 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.
Yep. In fact, it defines a richer environment than POSIX. However, I
_think_ that for any POSIX ACL, you can define an NFSv4 list which is
equivalent in all details (although the reverse is definitely not
true).
So, it should be possible for even an NFSv4 client implementation to
accept an ATR_POSIXACL request, and for it to construct an appropriate
ACL to pass to the server.
> 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.
Yep. So, in theory we can accept POSIX ACLs whether the underlying
filesystem is NFSv4, ext2+acls, or XFS. However, _if_ the filesystem
is NFSv4, then there is some required functionality which we cannot
support without a richer API.
This is exactly why we need a versioned API. If all the user wants to
do is to set an ACL which grants access rights to a couple of other
local users, then the ATR_POSIXACL family can be used and the request
will Just Work, regardless of the underlying filesystem (assuming that
the implementation has bothered to implement a mapping from POSIX to
NFSv4 acls --- we don't require that, but we'll support it if such a
mapping exists.)
If we are using a distributed filesystem and want to set an ACE for a
foreign user, then we have to resort to a different API --- in my
proposed model, this means using a different attribute family.
However, the user can still use the same names for local users if
desired --- you can mix UNIX and UTF8 names in the ACL in my API, for
exactly these reasons.
> > > 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.
But we're talking about the ACL API. That API is running on the
client, by definition.
And, guess what, exactly the same sort of arguments apply to
attributes. Some filesystems will implement different inheritance and
default-value semantics for named attributes. We can still define a
common core, ATR_USER, for access to simple "just set this attribute
on this file and don't give me any fancy inheritance semantics", and
the request will work regardless of whether it is ext2 or NTFS or
NFSv4 or XFS underneath. For more complex filesystems which offer
extra semantics such as a privileged (superuser, capabilities-based or
file-owner-based) attributes, we can define other attribute families
to let the user tell the kernel what the user wants. If there happens
to be a sane mapping from what the user wants to what the particular
filesystem supports, then the request can succeed, but we don't force
all filesystems to implement any one particular set of semantics.
That is the core of the reasoning behind the original API I proposed,
and this sort of versioning information is *critical* to the success
of the API in my opinion. Other details such as whether we offer
atomic test-and-get or a versioned API for atomic updates, or whether
the different "families" are specified by text prefixes or by
attribute family #defines as networking uses, are minor details in
comparison.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
