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
------=_Part_911526_1940532181.1399037792542 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Craig Yoshioka wrote: >=20 > On May 1, 2014, at 5:48 PM, Rick Macklem <rmacklem@uoguelph.ca> > wrote: >=20 > > Craig Yoshioka wrote: > >> I=E2=80=99ve posted this same email to the linux NFS mailing list sinc= e I > >> think it might be client-side problem, but thought I might look > >> for > >> input here as well. > >>=20 > >> problem: when using chown as root on a nfs4 filesystem on newer > >> linux > >> releases file owners get sets to nobody. > >> the user type doesn=E2=80=99t seem to matter (/etc/passwd, LDAP= , > >> Samba4) > >>=20 > >> 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 ) > >>=20 > >> clues: > >>=20 > >> 1. working and non-working systems get to the same fchownat() > >> system > >> call with the same arguments (via strace). > >>=20 > >> example (identical on working and non-working client): > >> ... > >> fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) =3D 0 > >> close(1) =3D 0 > >> close(2) =3D 0 > >> close(4) =3D 0 > >> exit_group(0) =3D ? > >> +++ exited with 0 +++ > >>=20 > >> 2. working system sends NFSV4 SETATTR request with owner set to: > >> matlab@nimgs.com and non-working as 11111 (via wireshark) > >>=20 > > 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). > >=20 > > 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.) > >=20 >=20 > 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. >=20 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?). > >=20 >=20 > echo N >/sys/module/nfs/parameters/nfs4_disable_idmapping >=20 > was suggested for me on the client-side, which also worked after > restarting the idmap service and remounting. >=20 > > 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). > >=20 > > 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.) > >=20 > > 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. > >=20 > > rick >=20 > It seems it is now fixed, or as a workaround, one can set that client > side nfs parameter. I=E2=80=99m kinda glad FreeBSD didn=E2=80=99t take t= he 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=E2=80=99t find and return a user name?, so it=E2=80=99s likely FreeBS= D NFS4 > servers will still get calls with uid strings in the future. >=20 > >=20 > >>=20 > >>=20 > >> 3. I can=E2=80=99t rule out misconfiguration. but I=E2=80=99ve config= ured as > >> identically as I could, and tried a lot of small vairations. these > >> are my current settings (the pipefs settings are the distro > >> defaults) > >>=20 > >> _______________________________________________ > >> 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" >=20 > _______________________________________________ > 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" >=20 ------=_Part_911526_1940532181.1399037792542 Content-Type: text/x-patch; name=stringtouid.patch Content-Disposition: attachment; filename=stringtouid.patch Content-Transfer-Encoding: base64 LS0tIGZzL25mcy9uZnNfY29tbW9uc3Vicy5jLm9yaWcJMjAxNC0wNC0xOCAxNzoxNDoyMy4wMDAw MDAwMDAgLTA0MDAKKysrIGZzL25mcy9uZnNfY29tbW9uc3Vicy5jCTIwMTQtMDUtMDIgMDk6MjA6 NDcuMDAwMDAwMDAwIC0wNDAwCkBAIC02NSw2ICs2NSw3IEBAIHVpZF90IG5mc3J2X2RlZmF1bHR1 aWQ7CiBnaWRfdCBuZnNydl9kZWZhdWx0Z2lkOwogaW50IG5mc3J2X2xlYXNlID0gTkZTUlZfTEVB U0U7CiBpbnQgbmNsX21idWZfbWxlbiA9IE1MRU47CitpbnQgbmZzZF9lbmFibGVfc3RyaW5ndG91 aWQgPSAwOwogTkZTTkFNRUlETVVURVg7CiBORlNTT0NLTVVURVg7CiAKQEAgLTI2NDAsOSArMjY0 MSwxNCBAQCBuZnN2NF9zdHJ0b3VpZChzdHJ1Y3QgbmZzcnZfZGVzY3JpcHQgKm5kCiAJLyogSWYg YSBzdHJpbmcgb2YgZGlnaXRzIGFuZCBhbiBBVVRIX1NZUyBtb3VudCwganVzdCBjb252ZXJ0IGl0 LiAqLwogCXN0cjAgPSBzdHI7CiAJdHVpZCA9ICh1aWRfdClzdHJ0b3VsKHN0cjAsICZlbmRzdHIs IDEwKTsKLQlpZiAoKGVuZHN0ciAtIHN0cjApID09IGxlbiAmJgotCSAgICAobmQtPm5kX2ZsYWcg JiAoTkRfS0VSQlYgfCBORF9ORlNDTCkpID09IE5EX05GU0NMKSB7Ci0JCSp1aWRwID0gdHVpZDsK KwlpZiAoKGVuZHN0ciAtIHN0cjApID09IGxlbikgeworCQkvKiBBIG51bWVyaWMgc3RyaW5nLiAq LworCQlpZiAoKG5kLT5uZF9mbGFnICYgTkRfS0VSQlYpID09IDAgJiYKKwkJICAgICgobmQtPm5k X2ZsYWcgJiBORF9ORlNDTCkgIT0gMCB8fAorCQkgICAgICBuZnNkX2VuYWJsZV9zdHJpbmd0b3Vp ZCAhPSAwKSkKKwkJCSp1aWRwID0gdHVpZDsKKwkJZWxzZQorCQkJZXJyb3IgPSBORlNFUlJfQkFE T1dORVI7CiAJCWdvdG8gb3V0OwogCX0KIAkvKgpAQCAtMjg0NSw5ICsyODUxLDE0IEBAIG5mc3Y0 X3N0cnRvZ2lkKHN0cnVjdCBuZnNydl9kZXNjcmlwdCAqbmQKIAkvKiBJZiBhIHN0cmluZyBvZiBk aWdpdHMgYW5kIGFuIEFVVEhfU1lTIG1vdW50LCBqdXN0IGNvbnZlcnQgaXQuICovCiAJc3RyMCA9 IHN0cjsKIAl0Z2lkID0gKGdpZF90KXN0cnRvdWwoc3RyMCwgJmVuZHN0ciwgMTApOwotCWlmICgo ZW5kc3RyIC0gc3RyMCkgPT0gbGVuICYmCi0JICAgIChuZC0+bmRfZmxhZyAmIChORF9LRVJCViB8 IE5EX05GU0NMKSkgPT0gTkRfTkZTQ0wpIHsKLQkJKmdpZHAgPSB0Z2lkOworCWlmICgoZW5kc3Ry IC0gc3RyMCkgPT0gbGVuKSB7CisJCS8qIEEgbnVtZXJpYyBzdHJpbmcuICovCisJCWlmICgobmQt Pm5kX2ZsYWcgJiBORF9LRVJCVikgPT0gMCAmJgorCQkgICAgKChuZC0+bmRfZmxhZyAmIE5EX05G U0NMKSAhPSAwIHx8CisJCSAgICAgIG5mc2RfZW5hYmxlX3N0cmluZ3RvdWlkICE9IDApKQorCQkJ KmdpZHAgPSB0Z2lkOworCQllbHNlCisJCQllcnJvciA9IE5GU0VSUl9CQURPV05FUjsKIAkJZ290 byBvdXQ7CiAJfQogCS8qCi0tLSBmcy9uZnNzZXJ2ZXIvbmZzX25mc2Rwb3J0LmMub3JpZwkyMDE0 LTA0LTIzIDE5OjQxOjQ2LjAwMDAwMDAwMCAtMDQwMAorKysgZnMvbmZzc2VydmVyL25mc19uZnNk cG9ydC5jCTIwMTQtMDUtMDIgMDg6MTI6MzEuMDAwMDAwMDAwIC0wNDAwCkBAIC04MCw2ICs4MCw3 IEBAIHN0YXRpYyBpbnQgbmZzX2NvbW1pdF9ibGtzOwogc3RhdGljIGludCBuZnNfY29tbWl0X21p c3M7CiBleHRlcm4gaW50IG5mc3J2X2lzc3VlZGVsZWdzOwogZXh0ZXJuIGludCBuZnNydl9kb2xv Y2FsbG9ja3M7CitleHRlcm4gaW50IG5mc2RfZW5hYmxlX3N0cmluZ3RvdWlkOwogCiBTWVNDVExf Tk9ERShfdmZzLCBPSURfQVVUTywgbmZzZCwgQ1RMRkxBR19SVywgMCwgIk5ldyBORlMgc2VydmVy Iik7CiBTWVNDVExfSU5UKF92ZnNfbmZzZCwgT0lEX0FVVE8sIG1pcnJvcm1udCwgQ1RMRkxBR19S VywKQEAgLTkyLDYgKzkzLDggQEAgU1lTQ1RMX0lOVChfdmZzX25mc2QsIE9JRF9BVVRPLCBpc3N1 ZV9kZQogICAgICZuZnNydl9pc3N1ZWRlbGVncywgMCwgIkVuYWJsZSBuZnNkIHRvIGlzc3VlIGRl bGVnYXRpb25zIik7CiBTWVNDVExfSU5UKF92ZnNfbmZzZCwgT0lEX0FVVE8sIGVuYWJsZV9sb2Nh bGxvY2tzLCBDVExGTEFHX1JXLAogICAgICZuZnNydl9kb2xvY2FsbG9ja3MsIDAsICJFbmFibGUg bmZzZCB0byBhY3F1aXJlIGxvY2FsIGxvY2tzIG9uIGZpbGVzIik7CitTWVNDVExfSU5UKF92ZnNf bmZzZCwgT0lEX0FVVE8sIGVuYWJsZV9zdHJpbmd0b3VpZCwgQ1RMRkxBR19SVywKKyAgICAmbmZz ZF9lbmFibGVfc3RyaW5ndG91aWQsIDAsICJFbmFibGUgbmZzZCB0byBhY2NlcHQgbnVtZXJpYyBv d25lcl9uYW1lcyIpOwogCiAjZGVmaW5lCU1BWF9SRU9SREVSRURfUlBDCTE2CiAjZGVmaW5lCU5V TV9IRVVSSVNUSUMJCTEwMzEK ------=_Part_911526_1940532181.1399037792542--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1986981308.911529.1399037792545.JavaMail.root>