From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Subject: Re: [RFC] POSIX ACL kernel infrastructure Date: Fri, 9 Aug 2002 12:53:55 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <200208091253.55935.agruen@suse.de> References: <200208041546.35234.agruen@suse.de> <20020805132832.B5301@infradead.org> <20020809020223.GF731@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Linux-FSDevel , Olaf Kirch , Chris Mason , Jeff Mahoney Return-path: To: Nathan Scott , Christoph Hellwig In-Reply-To: <20020809020223.GF731@frodo> List-Id: linux-fsdevel.vger.kernel.org On Friday 09 August 2002 04:02, Nathan Scott wrote: > hi Andreas, > > On Mon, Aug 05, 2002 at 01:28:32PM +0100, Christoph Hellwig wrote: > > On Mon, Aug 05, 2002 at 02:11:33PM +0200, Andreas Gruenbacher wrote: > > > >From user space, yes. The get_posix_acl operation is currently used in > > > > nfsd; > > > > > > going via the xattr operations would be too expensive here. The > > > set_posix_acl operation is indeed not used so far; I think it makes > > > sense to add it for completeness' sake. > > > > I'm not fully convienced. > > Nor am I (I don't buy either the too expensive argument or the > need for unused ops). The kernel NFS daemon introduces a number of interesting problems in the kernel that no other component requires; the ACL permission masking hack is one of them. The hack affects NFSv2 and NFSv3 It is really important that encode_fattr and encode_fattr3, the functions that include the hack, are efficient; they are used in all the essential NFS RPCs. The two implementation choices are: * Use the get_posix_acl inode operation On Ext2, Ext3, ReiserFS the inode operation passes a handle to the ACL to the caller (no copying). The handle is in the cache after the first access, the cache is very effective. XFS currently seems not to implement the *_posix_acl inode operations. That's fine; just the NFS hack won't be able to mask permissions. * Go via the xattr ACL format The xattr interface uses pass-by-value by design. So this requires allocating a buffer, conversion from the file system into the xattr format, parsing the xattr format. The xattr format is in (with possible reverse endianness conversion). The get_posix_acl approach has the added benefit that other parts of the kernel interested in manipulating ACLs can do so easily and efficiently (though I don't see which ones that could be right now). If set_posix_acl really _must_ be removed I won't bang my head against a wall. Is this sufficient? > It also begins to add unnecessary stuff > to the VFS inode ops - when capabilities, MAC labels, and misc > other attributes come along, we don't want to be adding in ops > for each of them too (esp. considering many filesystems do not > support extended attributes at all). IMO getxattr() should be > all we ever need here. Those file systems not supporting some of the options are not affected. We only need to add stuff to the VFS for things that other parts of the kernel need to access independently of the real filesystem, in those cases where the accesses need to be faster than the xattr interface can be. > MS_POSIXACL from your earlier mail is a Good Thing, I think - > I'll switch XFS over to use that when I get some time (instead > of the inode flag we are currently using). Fine, I will also use that, instead of MS_NOUMASK. MS_POSIXACL is nice to have in the nfsd hack as well. Having it is not extremely clean design, and I will hate myself for giving in the day another mechanism requires the umask to be skipped which is not POSIX ACLs, though. Cheers, Andreas. ------------------------------------------------------------------ Andreas Gruenbacher SuSE Linux AG mailto:agruen@suse.de Deutschherrnstr. 15-19 http://www.suse.de/ D-90429 Nuernberg, Germany