Return-Path: bfields@fieldses.org Date: Thu, 11 Dec 2014 14:55:27 -0500 From: "J. Bruce Fields" To: Jeff Layton Cc: Ian Kent , Benjamin Coddington , David Howells , David =?utf-8?B?SMOkcmRlbWFu?= , linux-nfs@vger.kernel.org, SteveD@redhat.com Subject: Re: [PATCH 00/19] gssd improvements Message-ID: <20141211195527.GP20526@fieldses.org> References: <20141210091734.3c612514@tlielax.poochiereds.net> <32108.1418227382@warthog.procyon.org.uk> <1418256763.2566.61.camel@pluto.fritz.box> <1418268081.2566.67.camel@pluto.fritz.box> <20141211064537.540e2e12@tlielax.poochiereds.net> <20141211193240.GO20526@fieldses.org> <20141211145029.4761b61e@tlielax.poochiereds.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20141211145029.4761b61e@tlielax.poochiereds.net> List-ID: On Thu, Dec 11, 2014 at 02:50:29PM -0500, Jeff Layton wrote: > On Thu, 11 Dec 2014 14:32:40 -0500 > "J. Bruce Fields" wrote: > > > On Thu, Dec 11, 2014 at 06:45:37AM -0500, Jeff Layton wrote: > > > For instance: module loading clearly needs to be done in the "context" > > > of the canonical root init process. That's what call_usermodehelper was > > > originally used for so we need to keep that ability intact. > > > > > > OTOH, keyring upcalls probably ought to be done in the context of the > > > task that triggered them. Certainly we ought to be spawning them with > > > the credentials associated with the keyring. > > > > Isn't the idmapping done as a keyring upcall? You don't want ordinary > > users of the filesystem to be able to pollute the id<->name cache. > > > > Yes, it is done as a keyring upcall. You wouldn't need to allow random > users to pollute the cache. When you do a keys upcall the process gets > an authorization key that allows it to instantiate the key. > > AFAIU, that's what guards against random processes polluting the > keyring, not any particular capabilities or anything. That doesn't stop it from instantiating the key with the wrong information. > > And in the gssd case, userland doesn't just find the right cred, it also > > does the rpcsec_gss context setup with the server. A random user of the > > filesystem might not be able to do that part. > > > > I don't see why not. We already do that today as an unprivileged user > in gssd. process_krb5_upcall forks and changes identity before getting > a ticket and setting up the context and then handing that back to the > kernel. I don't think that requires any special privileges. Why couldn't you give a task access to an nfs filesystem but wall it off in a network namespace where it doesn't even have access to the interface that the mount was done over? (And similarly what's to guarantee that a user of the filesystem is capable of doing the ldap calls you might need for idmapping?) --b.