From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr name Date: Thu, 28 Feb 2008 17:26:13 -0800 (PST) Message-ID: <227831.22689.qm@web36606.mail.mud.yahoo.com> References: <1204246206.7363.13.camel@heimdal.trondhjem.org> Reply-To: casey@schaufler-ca.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Dave Quigley , Stephen Smalley , casey@schaufler-ca.com, viro@ftp.linux.org.uk, bfields@fieldses.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, LSM List To: Trond Myklebust , Christoph Hellwig Return-path: In-Reply-To: <1204246206.7363.13.camel@heimdal.trondhjem.org> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org --- Trond Myklebust wrote: > > On Thu, 2008-02-28 at 19:39 -0500, Christoph Hellwig wrote: > > On Thu, Feb 28, 2008 at 07:04:57PM -0500, Dave Quigley wrote: > > > There are several things here. I've spoken to several people about this > > > and the belief I've gotten from most of them is that a recommended > > > attribute is how this is to be transported. The NFSv4 spec people will > > > probably say that if you want xattr like functionality for NFSv4 use > > > named attributes. For us this is not an option since we require > > > semantics to label on create/open and the only way we can do this is by > > > adding a recommended attribute. The create/open calls in NFSv4 takes a > > > list of attributes to use on create as part of the request. I really > > > don't see a difference between the security blob and the > > > username/groupname that NFSv4 currently uses. Also there is a good > > > chance that we will need to translate labels at some point (read future > > > work). > > > > Then use the existing side-band protocol and ignore the NFSv4 spec > > group. They're anyway. > > As I've told you several times before: we're _NOT_ putting private > ioctl^Hxattrs onto the wire. If the protocol can't be described in an > RFC, then it isn't going in no matter what expletive you choose to > use... With the SGI supplied reference implementation it ought to be a small matter of work to write an RFC. If the information weren't SGI proprietary I could even tell you how long it ought to take a junior engineer in Melbourne to write. The fact that there is currently no RFC does not mean that there cannot be a RFC, only that no one has written (or published) one yet. Casey Schaufler casey@schaufler-ca.com