On Mon, Chris Gerhard wrote: > Spencer Shepler wrote: > >On Thu, Chris Gerhard wrote: > >>My laptop lives in two separate environments, work and home, both have > >>NFS services but the name spaces are not the same. My login name at home > >>is not the same as my login name at work. > >> > >>With NFS versions 2 & 3 I could get a good approximation to a working NFS > >>system by using the same UID for me at home as I have at work. > >> > >>With NFS v4 that no longer works however I think I should now be able map > >>one user to another so that my laptop knows that when it is on one > >>network it maps work_login at sun.com to be home_login at home.network so > >>that > >>NFS will work. However I can see no way to actually achieve this. > >> > >>Is there a way? > > > >No, there isn't. The current design of the Solaris NFSv4 client is > >not targeted at a nomadic client. So, the first step would be to > >have a reasonable method to easily change the NFSv4 damain at the > >client when the change in context occurs. Actually, it may be interesting > >to think about a method of specifying domain per server for cases > >such as yours; hard to manage but possible. > > > > For my specific case I don't have to worry about ever accessing the home > network and the work network at the same time so having a big switch is > not a problem. > > While I was testing a prototype for a big switch solution to this which > I will write up later I've come across an apparent anomaly in that the > numeric UID is still used, without any mapping, when creating objects. > > So while listing an object the server tells me that it is owned by > home_login at home.network which nfsmapid then has to deal with but when > the client creates an object it uses it's local UID which is passed over > in the AUTH_SYS authentication in the RPC layer. Rather than passing it > as work_login at home.network which the server would then map to nobody > (which then upsets things like nautilus who decide that you don't have > access to the file you have just created). > > This has the side effect of making NFSv4 still require that my numeric > UID is always the same on all systems, as was the case with NFS v2 & v3, > with the additional headache that the user names must also be the same > (although that can be fixed with a modified nfsmapid daemon). > > So I'm left a bit confused as to the purpose of passing the owner and > group attributes as an NFS specific strings, rather than using the same > scheme as is used by the current authentication flavour?
Your observations are correct. For AUTH_SYS, the client is still identifying users by uid/gid-set and for object creation, the NFS server will use the RPC credentials for creation instead of trusting the uid/gid in the create request. For Kerberos, this wouldn't be an issue since the client and server will be mapping back and forth between principal and local representation. More broadly defined, the problem you are running into is a method with which the client manages identity when dealing with multiple user/group management domains. Spencer
