From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC][PATCH] Generic fallback for security xattrs Date: Fri, 19 Aug 2005 19:02:44 +0100 Message-ID: <20050819180244.GA5727@infradead.org> References: <1124474276.32663.134.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linuxfs , Andreas Gruenbacher , Darrel Goeddel , James Morris , Chris Wright , Alexander Viro , Christoph Hellwig Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:720 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S964943AbVHSSCs (ORCPT ); Fri, 19 Aug 2005 14:02:48 -0400 To: Stephen Smalley Content-Disposition: inline In-Reply-To: <1124474276.32663.134.camel@moss-spartans.epoch.ncsc.mil> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Aug 19, 2005 at 01:57:56PM -0400, Stephen Smalley wrote: > This is a request for comments (only) on the patch below that modifies > the VFS setxattr, getxattr, and listxattr code to fall back to the > security module for security xattrs if the filesystem does not support > xattrs natively. This allows security modules to export the incore > inode security label information to userspace even if the filesystem > does not provide xattr storage, and eliminates the need to > individually patch various pseudo filesystem types to provide such > access (note that this patch removes the existing xattr code from > devpts and tmpfs as it is then no longer needed). Note that this > approach may be controversial [1]; it has been suggested that we > should instead be modifying all filesystem types to support security > (and other) xattrs natively, but this seems questionable for legacy > filesystems like vfat and pseudo filesystems like proc, especially > when the resulting code will end up simply calling the security > framework to access the incore security label as with the current > devpts and tmpfs handlers. > > The patch restructures the code flow slightly to reduce duplication > between the normal path and the fallback path, but this should only have > one user-visible side effect - a program may get -EACCES rather than > -EOPNOTSUPP if policy denied access but the filesystem didn't support > the operation anyway. Note that the post_setxattr hook call is not > needed in the fallback case, as the inode_setsecurity hook call handles > the incore inode security state update directly. In contrast, we do > call fsnotify in both cases. > > Let me know what you think. Please do NOT apply yet. Very nice, and gets rid of lots of crap. Now that we started parsing the attribute name in generic code we should deprecate the old ->{get,set,list,remove}xattr inode operations and make the helpers James added a while ago mandatory for the future.