"Stephen C. Tweedie" wrote:
>
> On Sun, Oct 29, 2000 at 02:45:32PM +0100, Andreas Gruenbacher wrote:
> > 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.
Though this is not my field at all, I've been following this discussion
with interest and there's something I'm still missing. Why is it wrong
to have a privileged user space program take care of mapping utf/8 to
temporary uid? I'm sure there's a reason, I just can't see it.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
