[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
Paul Fisher wrote: > Just out of curiosity, is there a reason that RPC wasn't updated to > match the upper-level semantics with similar mechanics? That wouldn't be appropriate, really. People use a range of existing RPC security flavours with NFS (and, nowadays, a range of GSS mechanisms within the RPCSEC_GSS auth flavour), including UNIX, Diffie-Hellman & Kerberos. Of course, there already exist daemons that perform mappings between RPC security creds & UNIX uid/gid, e.g. keyserv, gssd, etc. The difficulty arises with NFSv4 wanting to have its own (informational) id mapping mechanism that is portable across all NFS platforms, without regard for the underling authentication, or transport, mechanisms, which may be totally different, or even non-existent, on some non-UNIX platforms. cheers, calum.
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
Note also, that although NFSv4 uses strings for uid/gid/domain, the underlying RPC layer uses the same authentication credentials as in previous NFS versions and other RPC programs. Since it's the RPC authentication that is used to control access, etc, don't expect too much from the NFSv4 name/id mapping. It's useful for ls -l listings, etc, but not for authentication. cheers, calum.
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
On Mon, 04 Aug 2008 17:45:41 +0200, Nicolas Williams wrote: > On Mon, Aug 04, 2008 at 10:37:04AM -0500, Paul Fisher wrote: >> I'm trying to use NFSv4 mounts and idmap to deal with differences in the >> uid/gid values between the server and clients. It is my understanding >> that NFSv4/idmap will map names->ids, and not use the id values >> directly. Is this correct? > > Sortof. > > NFSv4 uses names on the wire. > > The Solaris NFSv4 stack supports only one Unix domain, plus it supports > all of an Active Directory (Windows) forest. > > What you're trying to do, evidently, is use multiple Unix domains. We > don't support that yet. > >> - Domain = localnet (etch-01 -> /etc/idmapd.conf > > There is no idmapd.conf on Solaris. maybe there is some confusion by the inital poster wrt. to NFSv4 and idmap(1M) and nfsmapid(1M). NFSv4 uses the latter as a framework to map OTW usernames http://opensolaris.org/os/community/documentation/files/nfsmapid.html however as Nico pointed out nfsmapid(1M) is now also a client of idmap(1M) in order to support AD as done via: 6601949 nfsmapid should handle Windows users and groups in a heterogenous environment http://bugs.opensolaris.org/view_bug.do?bug_id=6601949 and as Nico also pointed out we don't support multiple Unix domain mappings. hth --- frankB
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
On Tue, Aug 05, 2008 at 09:56:01AM -0500, Paul Fisher wrote: > Just out of curiosity, is there a reason that RPC wasn't updated to > match the upper-level semantics with similar mechanics? It basically > shatters the wonderful illusion setup by NFSv4. Yes, there is: AUTH_SYS provides no security, and AUTH_SYS_NAMES (say) wouldn't either. But RPCSEC_GSS authentication mechanisms do. If you really need AUTH_SYS, then make sure that you share a UID/GID namespace across your servers and clients. Now, I think there's something to be said for the simplicity of AUTH_SYS in environments where one does not care about security. So perhaps we should have pursued an AUTH_SYS_NAMES anyways. But, a couple of observations: - if your environment is small enough, just sync your /etc/passwd and group files - otherwise deploy a distributed name service - either way AUTH_SYS will work fine for you then; - this could be an opportunity to learn Kerberos V. We have tools to make Kerberos deployment easy, you know: kdcmgr(1M) and kclient(1M). Nico --
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
Calum Mackay wrote: > Note also, that although NFSv4 uses strings for uid/gid/domain, the > underlying RPC layer uses the same authentication credentials as in > previous NFS versions and other RPC programs. > > Since it's the RPC authentication that is used to control access, etc, > don't expect too much from the NFSv4 name/id mapping. It's useful for ls > -l listings, etc, but not for authentication. > Thank you very much. That is a clear explanation of what is going on, and give the background why the AUTH_SYS fail to work as mentioned yesterday by Nicolas. So in the end NFSv4 idmap'ing is working exactly as I understood and expected (the output of ls -l worked when looking at the mounted home directory). It is just that I did not understand that the RPC transport which does access to the files (directory listings within the home directory, in this case) does not do string name based mapping. Just out of curiosity, is there a reason that RPC wasn't updated to match the upper-level semantics with similar mechanics? It basically shatters the wonderful illusion setup by NFSv4. -- paul
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
Frank Batschulat (Home) wrote: > On Mon, 04 Aug 2008 17:45:41 +0200, Nicolas Williams Sun.COM> wrote: > > >> On Mon, Aug 04, 2008 at 10:37:04AM -0500, Paul Fisher wrote: >> >>> I'm trying to use NFSv4 mounts and idmap to deal with differences in the >>> uid/gid values between the server and clients. It is my understanding >>> that NFSv4/idmap will map names->ids, and not use the id values >>> directly. Is this correct? >>> >> Sortof. >> >> NFSv4 uses names on the wire. >> >> The Solaris NFSv4 stack supports only one Unix domain, plus it supports >> all of an Active Directory (Windows) forest. >> >> What you're trying to do, evidently, is use multiple Unix domains. We >> don't support that yet. >> >> >>> - Domain = localnet (etch-01 -> /etc/idmapd.conf >>> >> There is no idmapd.conf on Solaris. >> > > maybe there is some confusion by the inital poster wrt. to NFSv4 and idmap(1M) > and nfsmapid(1M). NFSv4 uses the latter as a framework to map OTW usernames > > http://opensolaris.org/os/community/documentation/files/nfsmapid.html > I read this document, and it says that the client and server exchange UID and GID values as strings @domain and @domain. As long as the string names exist on the target and are of the same domain they are translated locally to UID/GID matching the name. Both the client (linux) and the server (opensolaris) are configured to use "localnet" as the idmap domain. This is exactly what I am expecting, so what am I mis-reading? -- paul
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
On Mon, Aug 04, 2008 at 11:39:40AM -0500, Paul Fisher wrote: > >AUTH_SYS -- don't use that. Use Kebreros (-o sec=krb5, krb5i or krb5p). > > Thanks, that sounds right. But this seems a bit unfortunate... > > Is using Kerberos the only alternative? This seems a little (hehe, read > a *lot*) heavy handed for my purposes (xVM virtual machines on my laptop > ;->). Frankly, I've never tried to configure Kerberos on either > opensolaris or linux. Your only alternatives: - use AUTH_NONE -- anonymous access (but I doubt you want that) - use RPCSEC_GSS - with Kerberos V (already covered) - with mech_dh (but not available on Linux) Nico --
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
Nicolas Williams wrote: > On Mon, Aug 04, 2008 at 11:22:58AM -0500, Paul Fisher wrote: > >> Actually no, only one nfs domain called "localnet" which is set on both >> the client and the server. What is different is that the client and >> server have a different idea of the actual uid/gid values that are used >> for the names (all in the local /etc files on each system). >> > > Provided you're using NFSv4 and you're NOT using AUTH_SYS, then this > will work. > > >> If NFSv4 idmap'ing uses names, but the uid/gid values on both sides need >> to match, what is the purpose of this translation layer? What am I >> missing here? >> > > AUTH_SYS -- don't use that. Use Kebreros (-o sec=krb5, krb5i or krb5p). > Thanks, that sounds right. But this seems a bit unfortunate... Is using Kerberos the only alternative? This seems a little (hehe, read a *lot*) heavy handed for my purposes (xVM virtual machines on my laptop ;->). Frankly, I've never tried to configure Kerberos on either opensolaris or linux. -- paul
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
On Mon, Aug 04, 2008 at 11:22:58AM -0500, Paul Fisher wrote: > Actually no, only one nfs domain called "localnet" which is set on both > the client and the server. What is different is that the client and > server have a different idea of the actual uid/gid values that are used > for the names (all in the local /etc files on each system). Provided you're using NFSv4 and you're NOT using AUTH_SYS, then this will work. > If NFSv4 idmap'ing uses names, but the uid/gid values on both sides need > to match, what is the purpose of this translation layer? What am I > missing here? AUTH_SYS -- don't use that. Use Kebreros (-o sec=krb5, krb5i or krb5p). > >There is no idmapd.conf on Solaris. > > > Um, did you missed that the client was Debian Etch Linux? Linux does in > fact have this file, which is where the idmap domain name is set. I did miss that. > If you look at the ls -l /export/home (on the os system), and ls -l > /home (on the etch-01 system) in the original post, you can see that the > name->id mapping seems to work for directory listings, but something > else is going on when accessing the contents. Right. See above. Your problem is AUTH_SYS. Nico --
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
Nicolas Williams wrote: > On Mon, Aug 04, 2008 at 10:37:04AM -0500, Paul Fisher wrote: > >> I'm trying to use NFSv4 mounts and idmap to deal with differences in the >> uid/gid values between the server and clients. It is my understanding >> that NFSv4/idmap will map names->ids, and not use the id values >> directly. Is this correct? >> > > Sortof. > > NFSv4 uses names on the wire. > > The Solaris NFSv4 stack supports only one Unix domain, plus it supports > all of an Active Directory (Windows) forest. > > What you're trying to do, evidently, is use multiple Unix domains. We > don't support that yet. > Actually no, only one nfs domain called "localnet" which is set on both the client and the server. What is different is that the client and server have a different idea of the actual uid/gid values that are used for the names (all in the local /etc files on each system). If NFSv4 idmap'ing uses names, but the uid/gid values on both sides need to match, what is the purpose of this translation layer? What am I missing here? >> - Domain = localnet (etch-01 -> /etc/idmapd.conf >> > > There is no idmapd.conf on Solaris. > Um, did you missed that the client was Debian Etch Linux? Linux does in fact have this file, which is where the idmap domain name is set. If you look at the ls -l /export/home (on the os system), and ls -l /home (on the etch-01 system) in the original post, you can see that the name->id mapping seems to work for directory listings, but something else is going on when accessing the contents. -- paul
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
On Mon, Aug 04, 2008 at 10:37:04AM -0500, Paul Fisher wrote: > I'm trying to use NFSv4 mounts and idmap to deal with differences in the > uid/gid values between the server and clients. It is my understanding > that NFSv4/idmap will map names->ids, and not use the id values > directly. Is this correct? Sortof. NFSv4 uses names on the wire. The Solaris NFSv4 stack supports only one Unix domain, plus it supports all of an Active Directory (Windows) forest. What you're trying to do, evidently, is use multiple Unix domains. We don't support that yet. > - Domain = localnet (etch-01 -> /etc/idmapd.conf There is no idmapd.conf on Solaris. Nico --
[nfs-discuss] nfs v4 idmap'ing not working (or "what am I doing wrong?")
I'm trying to use NFSv4 mounts and idmap to deal with differences in the uid/gid values between the server and clients. It is my understanding that NFSv4/idmap will map names->ids, and not use the id values directly. Is this correct? If so, something seems to be going wrong with my setup and I would appreciate the help to diagnose out what is wrong. Everything works mounting the nfs share on the client, and the idmap'ing appear to succeed, but when the user attempts to access the share contents "permission denied" is all that happens. Here are the details of the failure: - os is the nfs server, running OpenSolaris 2005.11 (build 94) - etch-01 is the nfs client, running Debian Etch (2.6.18-6 kernel) - ip addresses are os (192.168.2.62) and etch-01 (192.168.254.10) - NFSMAPID_DOMAIN = localnet (os -> /etc/default/nfs) - Domain = localnet (etch-01 -> /etc/idmapd.conf - automount is configured and working on client mount info on client: --- etch-01 # mount ... 192.168.2.62:/export/home/pfisher on /home/pfisher type nfs4 (rw,nosuid,nodev,noatime,sec=sys,proto=tcp,hard,intr,rsize=32768,wsize=32768,retrans=2,addr=192.168.2.62) failure on client: etch-01 # su - pfisher etch-01 $ ls ls: .: Permission denied server infomation on user and directory: -- os $ id pfisher uid=101(pfisher) gid=10(staff) groups=10(staff) os $ ls -l /export/home total 5 drwx-x 58 pfisher staff 91 2008-08-04 09:00 pfisher client infomation on user and directory: -- etch-01 # id pfisher uid=1000(pfisher) gid=103(pfisher) groups=103(pfisher),4(adm),24(cdrom),37(operator),50(staff),100(users) etch-01 # ls -l /home total 5 drwx-x 58 pfisher staff 91 Aug 4 2008 pfisher -- paul
