Re: NFSv3 UID/GID mapping

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Apr 23, 2004 at 12:12:05PM +0300, Ed V. Bartosh wrote:
> It's just a server-side mapping. I think we don't need to rely on
> client for that. There are many other possibilities to change uids on
> client side.

The situation where I can imagine it being useful is when you had a
client (maybe a laptop) that you wanted to be able to access shares on
servers in different uid domains (possibly simultaneously).

> Also client-based solution is less secure than server-side one and
> also it's the linux-only solution.

I don't see the argument there.

> I think there are many other situations when it may be useful to use
> this kind of mapping.

Sure.  I think someone on the linux kernel mailing list said they wanted
to able to squash ranges of uid's.

> > Do you also need to do map the id's in nfs3xdr.c:xdr_encode_setattr() and
> > xdr_decode_fattr()?
> Yes, I do. Thank you.

That means you need a second mapping: in addition to mapping remove
clients' id's to local server id's, you need the inverse mapping from
local id's to the clients' id's (to get ls right).

> > We need to figure out a way to do this without duplicating so much code
> > from nfs4idmap.c.
> Yes, we need it, but it's not too much code. I think that there is
> sense to move only deferred request handling functions somewhere in
> separate file and use it from nfs4 and nfs3 idmap functions.

OK.

> BTW, Is any chance for this functionality to be in mainstream sometime ?

It seems useful, but it's not really up to me.

--Bruce Fields


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs