On Thu, Apr 22, 2010 at 10:39 AM, Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote: > Stef Bon wrote: >> >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. Caching as in cache-fs? or as in caching user credentials? > 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. Yes, but not as easy as it sounds to ask the user anything (e.g. on "find /") even if kde/gnome desktop would popups on fist attempt to access each directory mounted to servers we don't have credentials or userid/password for (for this user). We need the userid/password or krb5 ticket to use to setup the session (we could ask winbind or the kernel keyring to provide this). I prefer longterm that cifs or its helpers don't do password storage, but rather some service such as winbind working with the kernel keyring do this - so it can be analyzed by more eyes to make sure it is secure. -- Thanks, Steve -- 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
