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? Is there a provision to delete or update NTLM credential? 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! -- 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
