Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: > As per LSF/MM summit discussion I am reposting the richacl patchset for > upstream inclusion. The patchset includes minimal changes required to > implement > a new acl model similar to NFSv4 ACL. The acl model selection is based on > file system feature flag. It'd also be nice to see the nfsd bits, as that (along with samba) is one of the main users. (And the richacl->NFSv4 acl mapping is tricky thanks to the mask bits.) --b. > > The following set of patches implements VFS and ext4 changes needed to > implement > a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, > extended by file masks to fit into the standard POSIX file permission model. > They are designed to work seamlessly locally as well as across the NFSv4 and > CIFS/SMB2 network file system protocols. > > A user-space utility for displaying and changing richacls is available at [1] > (a number of examples can be found at > http://acl.bestbits.at/richacl/examples.html). > > [1] git://github.com/kvaneesh/richacl-tools.git master > > To test richacl on ext4, create the file sytem with richacl feature flag > (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled > using mount option "acl" will switch to using richacl instead of posixacl. > > More details regarding richacl can be found at > http://acl.bestbits.at/richacl/ > > Previous posting of the patchset can be found at: > http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com > "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" > > The complete patchset can also be found at: > https://github.com/kvaneesh/linux/commits/richacl-for-upstream > > Since we are trying to get the changes merged upstream after a long time, I am > posting this as V1 again. I Also dropped the Acked-by tag from > David Howells and J. Bruce Fields . > Please let me know if I can add them back again. > > -aneesh > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: As per LSF/MM summit discussion I am reposting the richacl patchset for upstream inclusion. The patchset includes minimal changes required to implement a new acl model similar to NFSv4 ACL. The acl model selection is based on file system feature flag. It'd also be nice to see the nfsd bits, as that (along with samba) is one of the main users. (And the richacl-NFSv4 acl mapping is tricky thanks to the mask bits.) --b. The following set of patches implements VFS and ext4 changes needed to implement a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, extended by file masks to fit into the standard POSIX file permission model. They are designed to work seamlessly locally as well as across the NFSv4 and CIFS/SMB2 network file system protocols. A user-space utility for displaying and changing richacls is available at [1] (a number of examples can be found at http://acl.bestbits.at/richacl/examples.html). [1] git://github.com/kvaneesh/richacl-tools.git master To test richacl on ext4, create the file sytem with richacl feature flag (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled using mount option acl will switch to using richacl instead of posixacl. More details regarding richacl can be found at http://acl.bestbits.at/richacl/ Previous posting of the patchset can be found at: http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability The complete patchset can also be found at: https://github.com/kvaneesh/linux/commits/richacl-for-upstream Since we are trying to get the changes merged upstream after a long time, I am posting this as V1 again. I Also dropped the Acked-by tag from David Howells dhowe...@redhat.com and J. Bruce Fields bfie...@redhat.com. Please let me know if I can add them back again. -aneesh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner writes: > On Mon, Apr 28, 2014 at 10:54:52AM +0530, Aneesh Kumar K.V wrote: >> Dave Chinner writes: >> > On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: >> >> Hi >> >> >> >> As per LSF/MM summit discussion I am reposting the richacl patchset for >> >> upstream inclusion. The patchset includes minimal changes required to >> >> implement >> >> a new acl model similar to NFSv4 ACL. The acl model selection is based on >> >> file system feature flag. >> >> >> >> The following set of patches implements VFS and ext4 changes needed to >> >> implement >> >> a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, >> >> extended by file masks to fit into the standard POSIX file permission >> >> model. >> >> They are designed to work seamlessly locally as well as across the NFSv4 >> >> and >> >> CIFS/SMB2 network file system protocols. >> >> >> >> A user-space utility for displaying and changing richacls is available at >> >> [1] >> >> (a number of examples can be found at >> >> http://acl.bestbits.at/richacl/examples.html). > >> >> More details regarding richacl can be found at >> >> http://acl.bestbits.at/richacl/ >> >> >> >> Previous posting of the patchset can be found at: >> >> http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com >> >> "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" >> >> >> >> The complete patchset can also be found at: >> >> https://github.com/kvaneesh/linux/commits/richacl-for-upstream >> > >> > Where are the tests? We need comprehensive coverage in xfstests so >> > we can validate that it works the way it is supposed to and that we >> > don't break it in future, and that all filesystems behave the same >> > way >> > >> >> https://github.com/kvaneesh/richacl-tools/tree/master/test > > FYI, I doubt very much that anyone will run a stand-alone richacls > test suite regularly. Can you please work to integrate this into > xfstests so it becomes a regular part of a filesystem developer's > daily workflow? > Will update xfstest based on the progress made with this patchset. -aenesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner da...@fromorbit.com writes: On Mon, Apr 28, 2014 at 10:54:52AM +0530, Aneesh Kumar K.V wrote: Dave Chinner da...@fromorbit.com writes: On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: Hi As per LSF/MM summit discussion I am reposting the richacl patchset for upstream inclusion. The patchset includes minimal changes required to implement a new acl model similar to NFSv4 ACL. The acl model selection is based on file system feature flag. The following set of patches implements VFS and ext4 changes needed to implement a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, extended by file masks to fit into the standard POSIX file permission model. They are designed to work seamlessly locally as well as across the NFSv4 and CIFS/SMB2 network file system protocols. A user-space utility for displaying and changing richacls is available at [1] (a number of examples can be found at http://acl.bestbits.at/richacl/examples.html). More details regarding richacl can be found at http://acl.bestbits.at/richacl/ Previous posting of the patchset can be found at: http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability The complete patchset can also be found at: https://github.com/kvaneesh/linux/commits/richacl-for-upstream Where are the tests? We need comprehensive coverage in xfstests so we can validate that it works the way it is supposed to and that we don't break it in future, and that all filesystems behave the same way https://github.com/kvaneesh/richacl-tools/tree/master/test FYI, I doubt very much that anyone will run a stand-alone richacls test suite regularly. Can you please work to integrate this into xfstests so it becomes a regular part of a filesystem developer's daily workflow? Will update xfstest based on the progress made with this patchset. -aenesh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Mon, Apr 28, 2014 at 10:54:52AM +0530, Aneesh Kumar K.V wrote: > Dave Chinner writes: > > On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: > >> Hi > >> > >> As per LSF/MM summit discussion I am reposting the richacl patchset for > >> upstream inclusion. The patchset includes minimal changes required to > >> implement > >> a new acl model similar to NFSv4 ACL. The acl model selection is based on > >> file system feature flag. > >> > >> The following set of patches implements VFS and ext4 changes needed to > >> implement > >> a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, > >> extended by file masks to fit into the standard POSIX file permission > >> model. > >> They are designed to work seamlessly locally as well as across the NFSv4 > >> and > >> CIFS/SMB2 network file system protocols. > >> > >> A user-space utility for displaying and changing richacls is available at > >> [1] > >> (a number of examples can be found at > >> http://acl.bestbits.at/richacl/examples.html). > >> More details regarding richacl can be found at > >> http://acl.bestbits.at/richacl/ > >> > >> Previous posting of the patchset can be found at: > >> http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com > >> "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" > >> > >> The complete patchset can also be found at: > >> https://github.com/kvaneesh/linux/commits/richacl-for-upstream > > > > Where are the tests? We need comprehensive coverage in xfstests so > > we can validate that it works the way it is supposed to and that we > > don't break it in future, and that all filesystems behave the same > > way > > > > https://github.com/kvaneesh/richacl-tools/tree/master/test FYI, I doubt very much that anyone will run a stand-alone richacls test suite regularly. Can you please work to integrate this into xfstests so it becomes a regular part of a filesystem developer's daily workflow? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Mon, Apr 28, 2014 at 11:24:08AM +0530, Aneesh Kumar K.V wrote: > We already do that with richacl. Richacl already have most of the > details implemented in common code. Comparing to recent posix acl > changes we could still simplify chmod and xattr bits. I will do that > in the next update. There's still tons of duplication. There should be no code in the filesystem except for a few callouts for the inode init and chmod path, and the attr set/get should also be mostly in a library. If you need to add more than 20 lines to the filesystem you did something wrong. > > > - common data structure with Posix ACLs > > > > Can you explain this ?. Why do we want to do that ? One acl structure implementing the Posix and NFSv4 acls and instead of a big pile of duplicate infrastructure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Mon, Apr 28, 2014 at 11:24:08AM +0530, Aneesh Kumar K.V wrote: We already do that with richacl. Richacl already have most of the details implemented in common code. Comparing to recent posix acl changes we could still simplify chmod and xattr bits. I will do that in the next update. There's still tons of duplication. There should be no code in the filesystem except for a few callouts for the inode init and chmod path, and the attr set/get should also be mostly in a library. If you need to add more than 20 lines to the filesystem you did something wrong. - common data structure with Posix ACLs Can you explain this ?. Why do we want to do that ? One acl structure implementing the Posix and NFSv4 acls and instead of a big pile of duplicate infrastructure. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Mon, Apr 28, 2014 at 10:54:52AM +0530, Aneesh Kumar K.V wrote: Dave Chinner da...@fromorbit.com writes: On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: Hi As per LSF/MM summit discussion I am reposting the richacl patchset for upstream inclusion. The patchset includes minimal changes required to implement a new acl model similar to NFSv4 ACL. The acl model selection is based on file system feature flag. The following set of patches implements VFS and ext4 changes needed to implement a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, extended by file masks to fit into the standard POSIX file permission model. They are designed to work seamlessly locally as well as across the NFSv4 and CIFS/SMB2 network file system protocols. A user-space utility for displaying and changing richacls is available at [1] (a number of examples can be found at http://acl.bestbits.at/richacl/examples.html). More details regarding richacl can be found at http://acl.bestbits.at/richacl/ Previous posting of the patchset can be found at: http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability The complete patchset can also be found at: https://github.com/kvaneesh/linux/commits/richacl-for-upstream Where are the tests? We need comprehensive coverage in xfstests so we can validate that it works the way it is supposed to and that we don't break it in future, and that all filesystems behave the same way https://github.com/kvaneesh/richacl-tools/tree/master/test FYI, I doubt very much that anyone will run a stand-alone richacls test suite regularly. Can you please work to integrate this into xfstests so it becomes a regular part of a filesystem developer's daily workflow? Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Christoph Hellwig writes: > This doesn't address any or the previous points: > > - common implementation instead of the godawful boilerplate code >(and we even fixed most of this for Posix ACL by now, so even less >reason to do the same crap again!) We already do that with richacl. Richacl already have most of the details implemented in common code. Comparing to recent posix acl changes we could still simplify chmod and xattr bits. I will do that in the next update. > - common data structure with Posix ACLs > Can you explain this ?. Why do we want to do that ? > And of course no real explanation why we need the braindead access/deny > scheme at how it will get properly integrated with the system. > > So in this for a clear NAK. -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner writes: > On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: >> Hi >> >> As per LSF/MM summit discussion I am reposting the richacl patchset for >> upstream inclusion. The patchset includes minimal changes required to >> implement >> a new acl model similar to NFSv4 ACL. The acl model selection is based on >> file system feature flag. >> >> The following set of patches implements VFS and ext4 changes needed to >> implement >> a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, >> extended by file masks to fit into the standard POSIX file permission model. >> They are designed to work seamlessly locally as well as across the NFSv4 and >> CIFS/SMB2 network file system protocols. >> >> A user-space utility for displaying and changing richacls is available at [1] >> (a number of examples can be found at >> http://acl.bestbits.at/richacl/examples.html). >> >> [1] git://github.com/kvaneesh/richacl-tools.git master >> >> To test richacl on ext4, create the file sytem with richacl feature flag >> (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled >> using mount option "acl" will switch to using richacl instead of posixacl. > > No mount options, please. The ACL configuration needs to be > determined solely by the superblock feature bit - we cannot support > filesystems with mixed ACL types, and that's what this mount option > does. For ext4 since acls are enabled by default we really don't need to speciy -o acl in mount. What i meant by above is that using "acl/noacl" mount option will now enabe/disable POSIX or RICHacl based on the superblock feature bit. > >> More details regarding richacl can be found at >> http://acl.bestbits.at/richacl/ >> >> Previous posting of the patchset can be found at: >> http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com >> "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" >> >> The complete patchset can also be found at: >> https://github.com/kvaneesh/linux/commits/richacl-for-upstream > > Where are the tests? We need comprehensive coverage in xfstests so > we can validate that it works the way it is supposed to and that we > don't break it in future, and that all filesystems behave the same > way > https://github.com/kvaneesh/richacl-tools/tree/master/test -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
This doesn't address any or the previous points: - common implementation instead of the godawful boilerplate code (and we even fixed most of this for Posix ACL by now, so even less reason to do the same crap again!) - common data structure with Posix ACLs And of course no real explanation why we need the braindead access/deny scheme at how it will get properly integrated with the system. So in this for a clear NAK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: > Hi > > As per LSF/MM summit discussion I am reposting the richacl patchset for > upstream inclusion. The patchset includes minimal changes required to > implement > a new acl model similar to NFSv4 ACL. The acl model selection is based on > file system feature flag. > > The following set of patches implements VFS and ext4 changes needed to > implement > a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, > extended by file masks to fit into the standard POSIX file permission model. > They are designed to work seamlessly locally as well as across the NFSv4 and > CIFS/SMB2 network file system protocols. > > A user-space utility for displaying and changing richacls is available at [1] > (a number of examples can be found at > http://acl.bestbits.at/richacl/examples.html). > > [1] git://github.com/kvaneesh/richacl-tools.git master > > To test richacl on ext4, create the file sytem with richacl feature flag > (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled > using mount option "acl" will switch to using richacl instead of posixacl. No mount options, please. The ACL configuration needs to be determined solely by the superblock feature bit - we cannot support filesystems with mixed ACL types, and that's what this mount option does. > More details regarding richacl can be found at > http://acl.bestbits.at/richacl/ > > Previous posting of the patchset can be found at: > http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com > "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" > > The complete patchset can also be found at: > https://github.com/kvaneesh/linux/commits/richacl-for-upstream Where are the tests? We need comprehensive coverage in xfstests so we can validate that it works the way it is supposed to and that we don't break it in future, and that all filesystems behave the same way Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: Hi As per LSF/MM summit discussion I am reposting the richacl patchset for upstream inclusion. The patchset includes minimal changes required to implement a new acl model similar to NFSv4 ACL. The acl model selection is based on file system feature flag. The following set of patches implements VFS and ext4 changes needed to implement a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, extended by file masks to fit into the standard POSIX file permission model. They are designed to work seamlessly locally as well as across the NFSv4 and CIFS/SMB2 network file system protocols. A user-space utility for displaying and changing richacls is available at [1] (a number of examples can be found at http://acl.bestbits.at/richacl/examples.html). [1] git://github.com/kvaneesh/richacl-tools.git master To test richacl on ext4, create the file sytem with richacl feature flag (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled using mount option acl will switch to using richacl instead of posixacl. No mount options, please. The ACL configuration needs to be determined solely by the superblock feature bit - we cannot support filesystems with mixed ACL types, and that's what this mount option does. More details regarding richacl can be found at http://acl.bestbits.at/richacl/ Previous posting of the patchset can be found at: http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability The complete patchset can also be found at: https://github.com/kvaneesh/linux/commits/richacl-for-upstream Where are the tests? We need comprehensive coverage in xfstests so we can validate that it works the way it is supposed to and that we don't break it in future, and that all filesystems behave the same way Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
This doesn't address any or the previous points: - common implementation instead of the godawful boilerplate code (and we even fixed most of this for Posix ACL by now, so even less reason to do the same crap again!) - common data structure with Posix ACLs And of course no real explanation why we need the braindead access/deny scheme at how it will get properly integrated with the system. So in this for a clear NAK. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner da...@fromorbit.com writes: On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: Hi As per LSF/MM summit discussion I am reposting the richacl patchset for upstream inclusion. The patchset includes minimal changes required to implement a new acl model similar to NFSv4 ACL. The acl model selection is based on file system feature flag. The following set of patches implements VFS and ext4 changes needed to implement a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, extended by file masks to fit into the standard POSIX file permission model. They are designed to work seamlessly locally as well as across the NFSv4 and CIFS/SMB2 network file system protocols. A user-space utility for displaying and changing richacls is available at [1] (a number of examples can be found at http://acl.bestbits.at/richacl/examples.html). [1] git://github.com/kvaneesh/richacl-tools.git master To test richacl on ext4, create the file sytem with richacl feature flag (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled using mount option acl will switch to using richacl instead of posixacl. No mount options, please. The ACL configuration needs to be determined solely by the superblock feature bit - we cannot support filesystems with mixed ACL types, and that's what this mount option does. For ext4 since acls are enabled by default we really don't need to speciy -o acl in mount. What i meant by above is that using acl/noacl mount option will now enabe/disable POSIX or RICHacl based on the superblock feature bit. More details regarding richacl can be found at http://acl.bestbits.at/richacl/ Previous posting of the patchset can be found at: http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability The complete patchset can also be found at: https://github.com/kvaneesh/linux/commits/richacl-for-upstream Where are the tests? We need comprehensive coverage in xfstests so we can validate that it works the way it is supposed to and that we don't break it in future, and that all filesystems behave the same way https://github.com/kvaneesh/richacl-tools/tree/master/test -aneesh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Christoph Hellwig h...@infradead.org writes: This doesn't address any or the previous points: - common implementation instead of the godawful boilerplate code (and we even fixed most of this for Posix ACL by now, so even less reason to do the same crap again!) We already do that with richacl. Richacl already have most of the details implemented in common code. Comparing to recent posix acl changes we could still simplify chmod and xattr bits. I will do that in the next update. - common data structure with Posix ACLs Can you explain this ?. Why do we want to do that ? And of course no real explanation why we need the braindead access/deny scheme at how it will get properly integrated with the system. So in this for a clear NAK. -aneesh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
