From owner-freebsd-stable@FreeBSD.ORG Fri May 2 02:43:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4322CEF5 for ; Fri, 2 May 2014 02:43:46 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE6A1BD6 for ; Fri, 2 May 2014 02:43:45 +0000 (UTC) MIME-version: 1.0 Received: from hobbes.nimgs.com ([76.93.165.1]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N4X00HHOE8U7L50@st11p02mm-asmtp002.mac.com> for freebsd-stable@freebsd.org; Fri, 02 May 2014 02:43:44 +0000 (GMT) Subject: Re: problems with chown as root on nfs4 export From: Craig Yoshioka In-reply-to: <1901966946.615625.1398991683337.JavaMail.root@uoguelph.ca> Date: Thu, 01 May 2014 19:43:41 -0700 Message-id: <9ADAA4E7-9EA4-48C3-B039-7895E7FF82BE@me.com> References: <1901966946.615625.1398991683337.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHBEKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCH2hfH3lPGXhzB x4YGhgeGUIeEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGx0QGx4aHxsRCl5ZF2FHYVg cEQpMRhdia2sRCkNaFx0cBBMZBBscHwQbEQpCXhcbEQpEWBcYEQpESRcbEQpCRRdoT2NlUAFDb XpyWhEKQk4XbHBgeUAdYlJpGmIRCkJMF2B9c2hAf2h9UlNkEQpCbBdjGWtHEhlrUmRNYBEKQkA XbU9LXB5SZEEbaGIRCnBnF2NGGG9CcHtDHWUeEQpwaBdoHGNeGEFbTFseGBEKcGgXYmsYXEBaY 2dTX0ARCnBoF2tze2BZc1JtSWUZEQpwaBdmYEhdS0Fwf2VTehEKcGgXYHNGT3lNHllfY0MRCnB nF2ZyaBpdY05lWUZaEQpwfxdtGxp5e21bf0hFbhEKcF8XaH5cRnJPUEdeUGQRCnBnF2cdGkt9E mMfX0AeEQpwbBdkE3J9aUR5WR5yfREKcEwXYFlSE0NER09fRVkR X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-05-02_01:2014-05-01,2014-05-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405020044 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 02:43:46 -0000 On May 1, 2014, at 5:48 PM, Rick Macklem 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 @ 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 @ 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"