Good discussion! A few pieces of information from AFS/Coda land below:
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen C.
> Tweedie
.....
> > 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.
>
Chown does require a modification of getpwnam - while the current owner of
the object will be given a local uid through the standard kernel path, the
new owner might be totally unknown and getpwnam may have to contact a
centralized name database.
> 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.
In fact the world local takes on two meanings. In a large local realm it is
not feasible for a client to cache the entire local realm's user database
and perform mappings. It also becomes highly impractical to give users the
same uid across systems. Interestingly, I think that neither Coda nor AFS
at present support uid mapping.
- Peter -
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
