On Wed, 2010-12-15 at 17:55 -0500, J. Bruce Fields wrote: > On Wed, Dec 15, 2010 at 05:29:28PM -0500, J. Bruce Fields wrote: > > On Wed, Dec 15, 2010 at 05:15:46PM -0500, Trond Myklebust wrote: > > > On Wed, 2010-12-15 at 16:48 -0500, J. Bruce Fields wrote: > > > > On Wed, Dec 15, 2010 at 03:32:08PM -0500, Trond Myklebust wrote: > > > > > On Wed, 2010-12-15 at 15:19 -0500, J. Bruce Fields wrote: > > > > > > > > > > > Could you give an example of a case in which all of the following are > > > > > > true?: > > > > > > - the administrator explicitly requests numeric id's (for > > > > > > example by setting nfs4_disable_idmapping). > > > > > > - numeric id's work as long as the client uses auth_sys. > > > > > > - they no longer work if that same client switches to krb5. > > > > > > > > > > Trivially: > > > > > > > > > > Server /etc/passwd maps trondmy to uid 1000 > > > > > Client /etc/passwd maps trondmy to uid 500 > > > > > > > > I understand that any problematic case would involve different > > > > name<->id mappings on the two sides. > > > > > > > > What I don't understand--and apologies if I'm being dense!--is what > > > > sequence of operations exactly would work in this situation if we > > > > automatically switch idmapping based on auth flavor, and would not work > > > > without it. > > > > > > > > Are you imagining a future client that is also able to switch auth > > > > flavors on the fly (say, based on whether a krb5 ticket exists or not), > > > > or just unmounting and remounting to change the security flavor? > > > > > > > > Are you thinking of creating a file under one flavor and accessing it > > > > under another? > > > > > > Neither. > > > > > > I'm quite happy to accept that my user may map to completely different > > > identities on the server as I switch authentication schemes. Fixing that > > > is indeed the administrator's problem. > > > > > > I'm thinking of the simple case of creating a file, and then expecting > > > to see that file appear labelled with the correct user id when I do 'ls > > > -l'. That should work irrespectively of the authentication scheme that I > > > choose. > > > > > > In other words, if I authenticate as 'trond' on my client or to the > > > kerberos server, then do > > > > > > touch foo > > > ls -l foo > > > > > > I should see a file that is owned by 'trond'. > > > > Thanks, understood; but then, this isn't about behavior that occurs when > > a user *changes* authentication flavors. > > > > It's about what happens when someone sets nfs4_disable_idmapping but > > shouldn't have. > > In other words, to make sure I understand: > > - Is this switching-on-auth flavor *just* there to protect > confused administrators against themselves? > - Or is there some reasons someone who knew what they were doing > would actually *need* that behavior? It is there to ensure that you can use different type of authentication when speaking to different servers, and still have it work without the administrator having to add special mount options. As I've said before, the uid-on-the-wire behaviour only makes sense with AUTH_SYS. It adds no value when authenticating using principals, and will in many (most?) cases end up doing the wrong thing. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
