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