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'.
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
