Date: Thu, 1 May 2014 22:26:25 -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: <504241600.660666.1398997585018.JavaMail.root@uoguelph.ca> In-Reply-To: <CC0E663B-B8F1-41C8-950B-AA949BA25F0A@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Craig Yoshioka wrote: > I=E2=80=99ve 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=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 I just looked at rfc-3530bis and it says that the client MUST accept the uid in a string for non-Kerberized mounts. For the server, there are two almost contradictory paragraphs. The first seems to say a server can accept uids in strings if it chooses to. The second states that it SHOULD support them for non-Kerberized mounts. (Here is the section.) I will note that this is currently an internet draft and not an RFC, so I think Linux has "jumped the gun". However I will email you a patch soon that allows this to be optionally enabled for the server. The 2 paras: To provide a greater degree of compatibility with NFSv3, which identified users and groups by 32-bit unsigned user identifiers and group identifiers, owner and group strings that consist of ASCII- encoded decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such support. The receiver may treat such a user or group string as representing the same user as would be represented by an NFSv3 uid or gid having the corresponding numeric value. A server SHOULD reject such a numeric value if the security mechanism is kerberized. I.e., in such a scenario, the client will already need to form "user@domain" strings. For any other security mechanism, the server SHOULD accept such numeric values. As an implementation note, the server could make such an acceptance be configurable. If the server does not support numeric values or if it is configured off, then it MUST return an NFS4ERR_BADOWNER error. If the security mechanism is kerberized and the client attempts to use the special form, then the server SHOULD return an NFS4ERR_BADOWNER error when there is a valid translation for the user or owner designated in this way. In that case, the client must use the appropriate user@domain string and not the special form for compatibility. rick >=20 >=20 > 3. I can=E2=80=99t rule out misconfiguration. but I=E2=80=99ve configure= d 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?504241600.660666.1398997585018.JavaMail.root>