On Thu, 22 Apr 2010 16:39:48 +0100 Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote: > Stef Bon wrote: > > 2010/4/21 Jeff Layton <jlayton@xxxxxxxxxx>: > > > On Wed, 21 Apr 2010 16:16:26 +0200 > > > Stef Bon <stefbon@xxxxxxxxx> 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) > > > > 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. > I see no reason why we need to limit a superblock to use a single CIFS session (and hence a single set of credentials). Adding extra layers of userspace stuff is just working around a limitation of the filesystem. Why shouldn't CIFS just use a proper set of credentials in the first place? I think multi-user CIFS should be as easy to deploy as NFS. > 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. > Maybe, but that seems like we're just adding userspace layers to work around a fundamental design limitation of Linux CIFS. There are good reasons to allow different users to access the same mountpoint. The main one being that it's simply more intuitive for administrators. We don't need these extra layers for other network filesystems (such as NFS). Why should CIFS be any different here? > 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. > I was thinking last night about changing this and trying to do this a little more cleanly using task credentials. I'm still trying to understand what I should key the lookup off of however. When a task tries to get access to the mount, what should we use to determine whether it uses a given session? Note that kerberized NFS uses the fsuid too, so there is some precedent for that. > 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. > What will you do if there is no user to type in the password? Consider crontab jobs, for instance. This is something we could certainly consider for the future but it's really a separate project I think. In fact, I may be mentoring someone for GSoC to add some infrastructure to allow storage NTLM creds via keyctl that CIFS could then use to establish sessions. The limitation of this to kerberos may not be long-lived. > 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. > > 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. > Sounds like it might be useful, but I'm not sure it's a general enough solution for this problem. It has some disadvantages. Extra setup and administration overhead being the big ones. It also means that you can't have a "shared" directory since you're requiring separate mountpoints for each local user. The solution I'm proposing will make a shared CIFS mount as easy to set up and deal with as it is with NFS. Which is to say, non-trivial but doable for the average sysadmin with a clue. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
