On Thu, 22 Apr 2010 16:56:55 +0200 Stef Bon <stefbon@xxxxxxxxx> 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) > 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@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
