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

[Steve French]

On Thu, Apr 22, 2010 at 10:39 AM, Jamie Lokier <jamie at shareable.org> wrote:
> Stef Bon wrote:

>> >I'll try to flesh out the
>> > description a bit more on the next respin of this set:
>> >
>> > Currently, CIFS will only uses a single set of credentials on a
>> > mountpoint, and those credentials are decided at mount time. This is
>> > fine if you only ever have a single user using that mountpoint. In many
>> > cases though, multiple users on a client may access the mount. When
>> > this happens, those users share the mount's credentials. This means
>> > that you can't enforce permissions on a per-user basis on a CIFS mount.
>> >
>> > Now, CIFS tries to do several kludgey things to get around this
>> > limitation. It tries to enforce permissions locally, particularly if
>> > you have unix extensions enabled (which allows the client to fetch
>> > ownership and mode info from the server), but this is an inherently
>> > broken and racy proposition -- you have to be able to map local uid's
>> > to the server's, for instance and you also are faced with the
>> > possibility that permissions can change after you check them.
>> >
>> > There are also problems with inode creation. If you create a file, the
>> > ownership on the server is generally set to whatever the mount creds
>> > map to, and that has no relation to the user actually accessing the
>> > mount. This leads to a very confusing problem that users sometimes hit
>> > where they "touch" a new file on a mount, and get an error back. The
>> > file is created, but the ownership and mode are set in such a way that
>> > utimes() on it fails when the client tries to enforce permissions.
>> >
>> > The idea with this set is to address the root cause and allow the
>> > client to use multiple sets of credentials based on the fsuid of the
>> > task accessing the mount. This is a little more involved than with a
>> > filesystem like NFS -- you have to establish a "session" with the
>> > server for each set of credentials.
>> >
>> > Clear as mud?
>>
>> Yes very clear, what you want, but to me the whole problem is strange!
>>
>> Using more than one set of credentials (if using those) looks to me a not logic.
>> NOt only because my construction (mount.md5key) is using seperate
>> mountpoints per user, pure
>> for securiity reasons. Another user is not allowed to access my mounts
>> (not only to smb shares but every mount)
>>
>> But apart from that, I think all the data (files,permissions,..)
>> depend on the credentials provided. The server "decides"
>> what the client can see. Now you want to make the mounpoint present
>> all the different "views" in one?
>>
>> I do not know this is possible. The client should maintain different
>> views (or sessions as you call it) and present the view to the user.
>> But what if a user which is not linked to any credentials on the
>> client accesses the mountpiont?
>
> Fwiw, I originally agreed with Jeff's idea but now prefer Stef's :-)
>
> In some ways this is an automount type of problem: When a new user
> accesses the mount, creating a new session (and asking for user
> credentials) is not unlike creating a new mount.
>
> If automount supported "per-user" style mounts, magically resolving to
> a different mounted fs depending in the accessing user's credentials,
> like the automounters of old could sometimes do :-) Would that solve
> the kernel part of this problem?
>
> I think it probably would.
>
> fsuid is probably the wrong decision input for this.  For simple
> setups, yes, but if you have the same user logged in but one instance
> has diferent credentials such as using "newgrp", auxiliary groups,
> SElinux and so on... each of those should be able to influence whether
> separate sessions are needed.
>
> As non-kerberos setups need some userspace to support asking for the
> password or whatever, perhaps this is a general purpose way forward
> with it: An autofs-like capability to intercept mountpoint traversals
> and upcall to userspace.
>
> 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?

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


-- 
Thanks,

Steve