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