On Mon, 10 Jan 2011 14:55:30 -0500 Roman Shtylman <shtylman@xxxxxxxxxxxx> wrote: > I have setup nfs4 with krb5 server and successfully mounted a client. Two > people can log into the client box and both access their respective shares and > not each other's. However, when one user (who lets say has root privs) uses > root to become the second user (using su) then that user can now access the > info of the user he became. > > I was under the impression that this should not be possible as the tickets for > access should still be tied to the first user they logged in as. Is this true? > Or do I have an error in my setup? > > Process: > Login as user A > (User B logs into the machine from another terminal) > sudo su B (to become user B on the machine) > <can now edit files which belong to B> > That's correct, or is at least in accordance with the design. The credcache is (usually) a file in /tmp. The kernel has to upcall to userspace for that information. To do that, it passes along the uid of the owner of the credcache. I think this is governed by the fsuid. When you "su" to another user, all of the uid's associated with the process are changed (real, effective, fs and saved). So, the uid passed to the upcall in this case is B's and not A's. This could potentially be "fixable" by moving the krb5 credcache into the per-session keyring and then teach nfs to do keys API upcalls to get the right blob. Not a trivial project, but it's doable. This is something that would be nice for CIFS and maybe AFS too. > If User B does not login before user A becomes user B, user A is not able to > edit user B's files even after he becomes user B. > I suspect that that's just a negative cache entry that will eventually time out. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
