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

[Jeff Layton]

On Wed, 21 Apr 2010 16:16:26 +0200
Stef Bon <stefbon at gmail.com> wrote:

> I'm sorry but what is a multisession mount?
> 
> Stef
> 

Sorry, I guess I should have been more clear. 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?
-- 
Jeff Layton <jlayton at redhat.com>