problems with chown as root on nfs4 export

[Rick Macklem]

Craig Yoshioka wrote:
> 
> On May 1, 2014, at 5:48 PM, Rick Macklem <rmacklem at 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 at 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 at 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 at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to
> >> "freebsd-stable-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stringtouid.patch
Type: text/x-patch
Size: 2355 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140502/497dba62/attachment.bin>