From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Thoughts on credential switching Date: Mon, 31 Mar 2014 14:06:01 -0400 Message-ID: <58D59025-ADA1-44CB-88E4-36BCEE763B64@primarydata.com> References: <20140326194847.0e994d0b@ipyr.poochiereds.net> <20140326202535.7d9b6f78@ipyr.poochiereds.net> <20140327070802.124fb34c@ipyr.poochiereds.net> <20140330130328.GB7172@thunk.org> <20140331075145.4bd76872@tlielax.poochiereds.net> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Theodore Ts'o , Andy Lutomirski , Jim Lieb , "Eric W. Biederman" , LSM List , "Serge E. Hallyn" , Kees Cook , Linux FS Devel , "linux-kernel@vger.kernel.org" , Dr Fields James Bruce To: Layton Jeff Return-path: In-Reply-To: <20140331075145.4bd76872@tlielax.poochiereds.net> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mar 31, 2014, at 7:51, Jeff Layton wrote: > On Sun, 30 Mar 2014 09:03:29 -0400 > "Theodore Ts'o" wrote: >=20 >> On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote: >>> I had some time to think about this last night... >>>=20 >>> While using a fd to pass around credentials is convenient, the dang= er >>> is that it's pretty opaque. You have a fd that you know has creds >>> attached to it, but it's hard to be certain what is going to change= =2E >>=20 >> I don't think that's a particularly tough problem. In general, the = fd >> isn't something that you would want to pass around, and so the proce= ss >> which generated it will know exactly what it contained. >>=20 >=20 > I think there's a bit more of a use-case for passing around such an f= d > via socket... >=20 > Part of the problem is that the traditional uid/gid switching glibc > wrappers are per-process. If we're proposing doing something like: >=20 > seteuid() > setegid() > setgroups() > fd =3D open() > (...and then revert the creds using same syscalls) >=20 > ...during the time that you're doing all of that, you can't really > allow any thread in the process to be doing something that requires > _other_ creds until you've completed the above. Umm=85 open() isn=92t the only operation that you want to be able to do= with an assumed user identity. You want mknod(), mkdir(), link(), unli= nk(), =85 Pretty much any interaction with the underlying filesystem ne= eds to use the right identity. > So, I could envision a program like ganesha firing up a separate > process to handle the credential switching and fd creation and then > handing those back to the main process via a unix domain socket. How about using the keyrings interface to atomically cache and retrieve= these user identities? We already have support for different types of = keys that store/retrieve different types of structured information. How= is this so different? Cheers Trond _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com -- To unsubscribe from this list: send the line "unsubscribe linux-securit= y-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html