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