From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [Labeled-nfs] [RFC v3] Security Label Support for NFSv4 Date: Tue, 14 Oct 2008 09:20:48 -0400 Message-ID: <1223990448.8907.1.camel@localhost> References: <1222707986-26606-1-git-send-email-dpquigl@tycho.nsa.gov> <48F400DD.50905@sparta.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: James Morris , "David P. Quigley" , labeled-nfs@linux-nfs.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, viro@zeniv.linux.org.uk, selinux@tycho.nsa.gov To: "Matthew N. Dodd" Return-path: In-Reply-To: <48F400DD.50905@sparta.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 2008-10-13 at 22:15 -0400, Matthew N. Dodd wrote: > James Morris wrote: > > On Mon, 29 Sep 2008, David P. Quigley wrote: > > > >> * New security flavor (auth_seclabel) to transport process label to > >> server. This is a derivative of auth_unix so it does not support > >> kerberos which has its own issues that need to be dealt with. > > > > This is a problem, as discussed last year: > > > > http://linux-nfs.org/pipermail/labeled-nfs/2007-November/000110.html > > > > We can't require the use of a new auth flavor which is incompatible with > > auth_gss. > > auth_seclabel demonstrates the flavor independent changes required for > any RPC layer process label transport. A GSS solution is currently > under discussion. Right, but I'm not particularly interested in merging "demonstration" code that might end up requiring permanent support. I'd very much like to see all of this get further through the IETF process before we talk about merging into mainline. Cheers Trond