Return-Path: Received: from smurfs.athenacr.com ([64.95.46.209]:40012 "EHLO sprinkles.inp.in.athenacr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754652Ab1AJUpe (ORCPT ); Mon, 10 Jan 2011 15:45:34 -0500 From: Roman Shtylman To: Jeff Layton Subject: Re: question about nfs4 with krb5 behavior Date: Mon, 10 Jan 2011 15:45:21 -0500 Cc: linux-nfs@vger.kernel.org References: <201101101455.30608.shtylman@athenacr.com> <20110110153504.0379874a@tlielax.poochiereds.net> In-Reply-To: <20110110153504.0379874a@tlielax.poochiereds.net> Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <201101101545.21890.shtylman@athenacr.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Monday, January 10, 2011 03:35:04 pm Jeff Layton wrote: > On Mon, 10 Jan 2011 14:55:30 -0500 > > Roman Shtylman 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) > > > > 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.