Re: question about nfs4 with krb5 behavior

[Roman Shtylman <shtylman@athenacr.com>]

On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote:
> On Mon, 10 Jan 2011 14:55:30 -0500
> 
> Roman Shtylman <shtylman@athenacr.com> 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.

AFS does not have this behavior. 

What is a best practice for handling this situation? Prevent "untrusted" 
machines from connecting to the nfs server? Basically any machine where a 
normal user can become root would be a potential problem?

Thanks for the quick response.

cheers,
~Roman

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