On Tue, 5 Oct 2010 22:24:01 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Tue, Oct 5, 2010 at 5:19 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > On Tue, 5 Oct 2010 17:01:18 -0500 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > >> In reviewing this patch which changes the show_options on cifs mounts > >> to not display the network username (when multiuser mount flag is > >> turned on) ie not display the username sent on SMB SessionSetup. > >> > > > > 1) with krb5 it's absolutely worthless since we generally manufacture a > > username based on the fsuid for multiuser mounts. > > krb5 has principal names ... not much different from usernames > CIFS doesn't deal with those directly. It upcalls to userspace for a SPNEGO blob and deals with it as an opaque object. Eventually, I'd like to move more of the SPNEGO code into the kernel, but even then the kernel will probably still treat the krb5 ticket as an opaque blob for the most part. > > 2) /proc/mounts is probably the wrong interface for such a thing. > > When/if we are able to make multiuser mounts using non-krb5 auth, then > > the user should be able to get at that info via the keyring... > > > >> 2) In the future can't the domain name differ as well (so should we > >> special case the domain name - or perhaps showing the default domain > >> is fine?) > >> > > > > Maybe. But for now there aren't multiple domains per mount. I think we > > ought to keep this as simple as possible. We can always change that > > later if the need arises. > > In the krb5 case you can have different realm names now but I agree > that we use the same default domain name for the mount. > Yes. I think if we want to do that, it's really a separate project. Currently, the domain= option is just used for NTLM auth. We could consider passing it in the krb5 upcall as a realm name, but no one has reported problems that require that as of yet. -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
