From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH 01/11] Security: Add hook to get full maclabel xattr name Date: Fri, 29 Feb 2008 11:50:28 -0800 Message-ID: <1204314629.7274.33.camel@heimdal.trondhjem.org> References: <850338.40421.qm@web36605.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Dave Quigley , Stephen Smalley , viro@ftp.linux.org.uk, bfields@fieldses.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, LSM List To: casey@schaufler-ca.com Return-path: In-Reply-To: <850338.40421.qm@web36605.mail.mud.yahoo.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2008-02-29 at 10:52 -0800, Casey Schaufler wrote: > So it sounds as if for an xattr protocol to be viable it would first > require that xattr semantics be generally accepted (POSIX definition > would suffice), that there be multiple implementations (Linux and Irix > could suffice should Irix still be around when POSIX is done), and > that there be a perceived need beyond that of the Lunitic Fringe > Security Community. The problem isn't that of supporting the naive user xattr model: we can almost do that within the existing 'named attribute' model of NFSv4. The problem is that of supporting the arbitrary "security metadata" that are allowed to have side-effects on the system behaviour, and that we appear to have thought was a good idea to overload onto the xattr interface. In the case of maclabels, where the "side-effect" is to describe and enable extra access control rules, then you have the potential for setting people up with a major interoperability problem. Using a dedicated interface for it instead of overloading a Linux-style xattr interface allows you to limit the scope of the documentation problem that you would otherwise have. Trond