> -----Original Message----- > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > owner@xxxxxxxxxxxxxxx] On Behalf Of Trond Myklebust > Sent: Thursday, December 02, 2010 3:18 PM > To: Thomas Haynes > Cc: J. Bruce Fields; Spelic; linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: NFSv4 behaviour on unknown users > > On Thu, 2010-12-02 at 17:10 -0600, Thomas Haynes wrote: > > On Dec 1, 2010, at 10:29 AM, J. Bruce Fields wrote: > > > > > On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote: > > >> > > >> I think you need to take beepy's words in context here: as I > > >> believe I mentioned previously, RFC3530 (and its predecessor > > >> RFC3010) assumed everyone would be using principals for > > >> authenticating, either through RPCSEC_GSS w/ krb5, or through the > > >> SPKM/Lipkey mechanism. So sure was everyone of this, that AUTH_SYS > > >> isn't even mentioned as a valid authentication mechanism, and so > > >> nobody had to worry about the consequences of using it. > > > > > > I also wonder whether the value of a transparent upgrade from NFSv3 > > > got a little lost. > > > > > > To me that seems like the first requirement for version n+1 of > > > anything--that we should be able to upgrade people to version n > > > without their noticing. > > > > > > Maybe there are features that are necessarily incompatible, and that > > > merit the downside, but the downside--losing the chance to get new > > > features to every user automatically--seems significant to me. > > > > > > > > > And, perhaps it's a disease, but I have gotten into the habit of > > > thinking of the (krb5 principal)->(id, gid's) mapping as independent > > > of the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid) > mappings. > > > > > > Granted they have to be coordinated on any reasonably complicated > setup. > > > But there are simple cases where they don't necessarily need to be. > > > > > > E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who" > > > does the backup as long as they have sufficient permissions, since > > > the files will all be explicitly chown'd as they're created. And > > > with krb5 it's simple enough to make that work with a single static > > > mapping from a client-side principal to root on the server. > > > > > > And, again, that's something that works now with NFSv3. > > > > > > --b. > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" > > > in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo > > > info at http://vger.kernel.org/majordomo-info.html > > > > > > Another question is whether or not such an approach would be > > appreciated as part of 3530bis? > > You want to add a discussion about AUTH_SYS support for 3530bis? I'd be OK > with that... What would the substance of such a discussion? The NFSv4 RFCs do not preclude the use of a variety of RPC authentication types. It asks that implementations treat the RPCSEC_GSS framework and the Kerberos and lipkey types as mandatory to implement. Given that the user of NFSv4 is not forced to use these or other authentication methods, does the discussion reside in the interaction with these various authentication types and their impact on the content of communicated attributes? In any case, I would suggest a treatment of these issues be captured in a separate I-D and ultimately a separate RFC to allow for expediency of publication and application to NFSv4.0 and NFSv4.1. Spencer -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
