Re: [linux-cifs-client] [PATCH 00/11] cifs: implement multisession mounts (try #2)

[Jamie Lokier <jamie@shareable.org>]

Steve French wrote:
> > Perhaps extending FUSE on the user side, if autofs isn't appropriate.
> > FUSE is very programmable, and the kernel side can cache some things.
> > If better caching is needed, that would be to everyone's benefit.
> 
> Caching as in cache-fs? or as in caching user credentials?

User credentials in this case.  I don't know if FUSE actually does
that - only that the architecture could go in that direction if useful.

> > That kind of approach would help other filesystems as much as CIFS.
> >
> > Of course all of this still needs the ability to create new CIFS
> > sessions when needed :-)  But triggering it from userspace has a lot of
> > advantages.
> 
> Yes, but not as easy as it sounds to ask the user anything
> (e.g. on "find /") even if kde/gnome desktop would popups on
> fist attempt to access each directory mounted to servers we don't
> have credentials or userid/password for (for this user).
> We need the userid/password or krb5 ticket to use to
> setup the session (we could ask winbind or the kernel keyring to
> provide this).  I prefer longterm that cifs or its helpers don't do password
> storage, but rather some service such as winbind working with
> the kernel keyring do this - so it can be analyzed by more eyes
> to make sure it is secure.

I agree it's not particularly easy, and I agree with _not_ storing
passwords in the kernel.

You seem to agree that a userspace helper should be involved
(winbind), and the keyring seems a natural thing to use kernel side,
which is really the same as what I've suggested, only I'd put a bit
more of the mount-traversal decision making and session setup into
'winbind-plus'.

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html