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

Jeff Layton jlayton at redhat.com
Thu Apr 22 11:51:05 MDT 2010


On Thu, 22 Apr 2010 16:56:55 +0200
Stef Bon <stefbon at gmail.com> wrote:

> 2010/4/21 Jeff Layton <jlayton at redhat.com>:
> > 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.
> 
> Well you dio not have to apologise!
> There is nothing wrong with asking.
> 
> >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)
> 

I'm sure your solution solves some problems, but it's I don't think it
precludes this work. We have users of CIFS who do something similar
today (albeit much more manually).

There are certainly cases where someone has a shared directory that
they need multiple users to access. Having to have a separate
mountpoint for each of those users seems rather cumbersome, IMO.

In either case, this is simply a different way to solve that issue.
This solution will not preclude you from using CIFS in the way you wish
(with a single set of credentials per 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?
> 

CIFS does not cache readdir info, so the server will still decide what
each user can "see" based on the credentials that call the FIND_FILE
ops. In the event of a syscall against a dentry that's visible to one
user but not another, a call will still go out over the wire before
that syscall is satisfied. Therefore I don't think this patchset will
allow information "leakage" to users that shouldn't have it.

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

There are a couple of possibilties. In the current patchset, they'll
get back an error when they try to access the mount -- -ENOKEY
currently in most cases, but I will likely need to translate that to
something that more syscalls will expect, such as -EACCES.

As a future feature, it might be helpful to establish an anonymous
session to the server and map users without credentials to that.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list