Date: Fri, 2 May 2014 09:36:32 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Craig Yoshioka <craigyk@me.com> Cc: freebsd-stable@freebsd.org Subject: Re: problems with chown as root on nfs4 export Message-ID: <1986981308.911529.1399037792545.JavaMail.root@uoguelph.ca> In-Reply-To: <9ADAA4E7-9EA4-48C3-B039-7895E7FF82BE@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Craig Yoshioka wrote: > > On May 1, 2014, at 5:48 PM, Rick Macklem <rmacklem@uoguelph.ca> > wrote: > > > Craig Yoshioka wrote: > >> I’ve posted this same email to the linux NFS mailing list since I > >> think it might be client-side problem, but thought I might look > >> for > >> input here as well. > >> > >> problem: when using chown as root on a nfs4 filesystem on newer > >> linux > >> releases file owners get sets to nobody. > >> the user type doesn’t seem to matter (/etc/passwd, LDAP, > >> Samba4) > >> > >> setup: Server is FreeBSD 10 system with NFSv4 share. > >> Server and clients are all configured with the same idmap > >> domain > >> Network users have consistent uid/gid on server and clients > >> clients with older linux releases work OK (Ubuntu 12.04, > >> CentOS > >> 5 and 6) > >> clients with newer linux releases do not work ( Fedora 20, > >> Ubuntu 14.04, Mint 16 ) > >> > >> clues: > >> > >> 1. working and non-working systems get to the same fchownat() > >> system > >> call with the same arguments (via strace). > >> > >> example (identical on working and non-working client): > >> ... > >> fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0 > >> close(1) = 0 > >> close(2) = 0 > >> close(4) = 0 > >> exit_group(0) = ? > >> +++ exited with 0 +++ > >> > >> 2. working system sends NFSV4 SETATTR request with owner set to: > >> matlab@nimgs.com and non-working as 11111 (via wireshark) > >> > > Yuck. RFC-3530 strongly encouraged use of <user>@<domain> names > > to identify users. rfc-3530bis (not yet an RFC afaik) "clarified" > > this to allow a server to return the number as a string (something > > done early in NFSv4 development for testing). > > > > This happened because Linux wanted to put the uid in a string so > > that NFSv4 mounted root file systems could be done more easily. > > (My understanding was that the client is now expected to understand > > a uid in a string, but I didn't think the server was required to > > accept it for a setattr.) > > > > From what I was told, trying a uid string is only a fallback scenario > for the client. Instead, it turns out root (uid 0) was improperly > triggering a conditional that mapped it to nobody on maproot > exports. I just tried a fixed version and it works now. > Well, the fallback is what I understand rfc-3530bis recommends for all clients. The current FreeBSD client does that fallback. However, there is also this snippet from rfc-3530bis: A client can determine if a server supports numeric identifiers by first attempting to provide a numeric identifier. If this attempt rejected with an NFS4ERR_BADOWNER error, then the client should only use named identifiers of the form "user@dns_domain". I'm guessing that NFS4ERR_BADOWNER would have been returned by the FreeBSD server for the numeric string case, but the Linux client didn't do this. (It is a "should", so it is not a required to be done. Same goes for the server allowing numeric strings.) Actually, I've attached a slightly updated patch that makes sure the server returns NFS4ERR_BADOWNER if the numeric string isn't supported. (If you haven't yet started testing the other patch, maybe you can test this one instead.) Thanks for your help with this, rick > > There is a configuration option in the Linux nfsd that disables > > this for the Linux server side (sorry, I can't remember what it is > > and I don't know if this same setting changes client behaviour?). > > > > echo N >/sys/module/nfs/parameters/nfs4_disable_idmapping > > was suggested for me on the client-side, which also worked after > restarting the idmap service and remounting. > > > This is the first time I've heard of the Linux client putting the > > uid in a string (but I guess I'm not surprised). > > > > Hopefully there is a mount (or configuration) option that tells > > it to use <user>@<domain> for the mount. If there isn't such a > > beast, changing the server to accept the uid as a string is easy, > > although I thought doing so actually violated RFC-3530. > > (I'll admit I haven't looked closely at a recent draft of > > rfc-3530bis to see what it says. This document wasn't supposed > > to change the protocol, but just clarify it, however I think it > > has gone beyond that.) > > > > If you can find a mount/configuration option, please email with > > that. If not, email and I'll give you a patch that can optionally > > allow the server to handle the uid in a string. > > > > rick > > It seems it is now fixed, or as a workaround, one can set that client > side nfs parameter. I’m kinda glad FreeBSD didn’t take the uid > because it would probably have masked the bug. OTH, it seems > sending the uid is still a possible fallback. maybe if the server > can’t find and return a user name?, so it’s likely FreeBSD NFS4 > servers will still get calls with uid strings in the future. > > > > >> > >> > >> 3. I can’t rule out misconfiguration. but I’ve configured as > >> identically as I could, and tried a lot of small vairations. these > >> are my current settings (the pipefs settings are the distro > >> defaults) > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to > >> "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > [-- Attachment #2 --] --- fs/nfs/nfs_commonsubs.c.orig 2014-04-18 17:14:23.000000000 -0400 +++ fs/nfs/nfs_commonsubs.c 2014-05-02 09:20:47.000000000 -0400 @@ -65,6 +65,7 @@ uid_t nfsrv_defaultuid; gid_t nfsrv_defaultgid; int nfsrv_lease = NFSRV_LEASE; int ncl_mbuf_mlen = MLEN; +int nfsd_enable_stringtouid = 0; NFSNAMEIDMUTEX; NFSSOCKMUTEX; @@ -2640,9 +2641,14 @@ nfsv4_strtouid(struct nfsrv_descript *nd /* If a string of digits and an AUTH_SYS mount, just convert it. */ str0 = str; tuid = (uid_t)strtoul(str0, &endstr, 10); - if ((endstr - str0) == len && - (nd->nd_flag & (ND_KERBV | ND_NFSCL)) == ND_NFSCL) { - *uidp = tuid; + if ((endstr - str0) == len) { + /* A numeric string. */ + if ((nd->nd_flag & ND_KERBV) == 0 && + ((nd->nd_flag & ND_NFSCL) != 0 || + nfsd_enable_stringtouid != 0)) + *uidp = tuid; + else + error = NFSERR_BADOWNER; goto out; } /* @@ -2845,9 +2851,14 @@ nfsv4_strtogid(struct nfsrv_descript *nd /* If a string of digits and an AUTH_SYS mount, just convert it. */ str0 = str; tgid = (gid_t)strtoul(str0, &endstr, 10); - if ((endstr - str0) == len && - (nd->nd_flag & (ND_KERBV | ND_NFSCL)) == ND_NFSCL) { - *gidp = tgid; + if ((endstr - str0) == len) { + /* A numeric string. */ + if ((nd->nd_flag & ND_KERBV) == 0 && + ((nd->nd_flag & ND_NFSCL) != 0 || + nfsd_enable_stringtouid != 0)) + *gidp = tgid; + else + error = NFSERR_BADOWNER; goto out; } /* --- fs/nfsserver/nfs_nfsdport.c.orig 2014-04-23 19:41:46.000000000 -0400 +++ fs/nfsserver/nfs_nfsdport.c 2014-05-02 08:12:31.000000000 -0400 @@ -80,6 +80,7 @@ static int nfs_commit_blks; static int nfs_commit_miss; extern int nfsrv_issuedelegs; extern int nfsrv_dolocallocks; +extern int nfsd_enable_stringtouid; SYSCTL_NODE(_vfs, OID_AUTO, nfsd, CTLFLAG_RW, 0, "New NFS server"); SYSCTL_INT(_vfs_nfsd, OID_AUTO, mirrormnt, CTLFLAG_RW, @@ -92,6 +93,8 @@ SYSCTL_INT(_vfs_nfsd, OID_AUTO, issue_de &nfsrv_issuedelegs, 0, "Enable nfsd to issue delegations"); SYSCTL_INT(_vfs_nfsd, OID_AUTO, enable_locallocks, CTLFLAG_RW, &nfsrv_dolocallocks, 0, "Enable nfsd to acquire local locks on files"); +SYSCTL_INT(_vfs_nfsd, OID_AUTO, enable_stringtouid, CTLFLAG_RW, + &nfsd_enable_stringtouid, 0, "Enable nfsd to accept numeric owner_names"); #define MAX_REORDERED_RPC 16 #define NUM_HEURISTIC 1031
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1986981308.911529.1399037792545.JavaMail.root>