On Fri, 16 Dec 2011 09:48:30 -0600 Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Thu, Dec 15, 2011 at 12:59 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > On Thu, 15 Dec 2011 12:20:15 -0600 > > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > > > >> On Thu, Dec 15, 2011 at 12:12 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > >> > This patchset is a cleanup and overhaul of the cifscreds utility that > >> > lives in the cifs-utils tree today. Igor Druzhinin did a wonderful job > >> > on this when he did the original code a couple of years ago, but I did a > >> > rather poor job at the time of communicating what we actually need for > >> > this tool to do. Mea culpa... > >> > > >> > This patch is a second pass at morphing it into a tool that's more like > >> > what we need. I believe with this, I'll be able to roll some kernel > >> > patches that can use the stashed key for establishing sessions. > >> > > >> > I've made a few changes since the last set: > >> > > >> > - combine some of the earlier patches so it's a smaller set > >> > > >> > - I've dropped the patch to make key_search use keyctl_search. I'd still > >> > like to do this differently, but for now it's not possible to do so > >> > and protect the key payload > >> > > >> > The idea here is that we want to be able to allow users to stash their > >> > NTLM credentials in the kernel, so that it's possible to establish a > >> > session on the fly when that user walks into a multiuser mount. > >> > >> Jeff, is there an initial/earlier document that states exactly how > >> a user can stash NTLM credentials? > >> > >> By NTLM credentials, it is meant that server/domain name/address > >> and corrosponding password etc.? > >> > > > > Correct. The idea here is that this tool stashes a key (or keys) in the > > session keyring with a name like: > > > > cifscreds:a:<IP Address> > > > > ...or: > > > > cifscreds:d:<NT Domain Name> > > > > ...that key has a payload that looks like this: > > > > <username>:<password> > > > > For a multiuser mount, when a user walks into the mount for the first > > time, the kernel can look for a key in the keyring for the right server, > > or failing that, the right NT domain. It can then get username and > > password info out of the payload to establish a session. > > > > We could also use this to get credentials for the initial mount too, > > but that use-case is less compelling. > > > > -- > > Jeff Layton <jlayton@xxxxxxxxx> > > Jeff, one of the concerns would be, how to sync up the pasword at the > server and domain. If the user password at the server changes, > user must make corrosponding changes at the client machine? Yes, at least prior to the next reconnect. Those are the perils of password-based auth. > Is there a provision to delete or update NTLM credential? Yes, the cifscreds command has delete and update functionality. > Also, if the same user can use multiple client machines to authenticate to the > same server or domain, should every client machine have a copy of > (the same) NTLM credentials stashed? And then if password changes, > user must remember to update NTLM credentials on each client machine! Yes. It's somewhat similar to the situation with kerberos tickets. This is just a way for users to securely store their username and password so we can use it for multiuser mounts. -- 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
