Date: Thu, 01 May 2014 19:43:41 -0700 From: Craig Yoshioka <craigyk@me.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-stable@freebsd.org Subject: Re: problems with chown as root on nfs4 export Message-ID: <9ADAA4E7-9EA4-48C3-B039-7895E7FF82BE@me.com> In-Reply-To: <1901966946.615625.1398991683337.JavaMail.root@uoguelph.ca> References: <1901966946.615625.1398991683337.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 1, 2014, at 5:48 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Craig Yoshioka wrote: >> I=92ve 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. >>=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=92t 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 =46rom 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. > 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 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.=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 It seems it is now fixed, or as a workaround, one can set that client = side nfs parameter. I=92m kinda glad FreeBSD didn=92t 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=92t find = and return a user name?, so it=92s likely FreeBSD NFS4 servers will = still get calls with uid strings in the future. >=20 >>=20 >>=20 >> 3. I can=92t rule out misconfiguration. but I=92ve 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) >>=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ADAA4E7-9EA4-48C3-B039-7895E7FF82BE>