linux-ext4 - [RFC PATCH] New ACL format for better NFSv4 acl interoperability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon,  1 Feb 2010 11:04:42 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	sfrench@...ibm.com, ffilz@...ibm.com, agruen@...e.de,
	adilger@....com, sandeen@...hat.com, tytso@....edu,
	staubach@...hat.com, bfields@...i.umich.edu, jlayton@...hat.com
Cc:	aneesh.kumar@...ux.vnet.ibm.com, linux-fsdevel@...r.kernel.org,
	nfsv4@...ux-nfs.org, linux-ext4@...r.kernel.org
Subject: [RFC PATCH] New ACL format for better NFSv4 acl interoperability

Hi,
	**** RFC patch. Not for inclusion ****

The following set of patches implements a new acl format
for linux. Rich-acl format is proposed so that we can have
better acl interoperability with CIFS and NFSv4 acl.

Posix acl should still be considered as the default acl on
any file system because of its simplicity. File systems
should provide a migration mechanism to rich-acl format if
they ever want to export these file systems via CIFS or NFSv4.

Some of the patches in the series are earlier published as
NFSv4 acl patches at http://www.suse.de/~agruen/nfs4acl/
and http://oss.sgi.com/projects/nfs/nfs4acl/. Linux kernel
already supports "system.nfs4_acl" via NFSv4 client. NFSv4
client provides byte sequence representation of the acl value
to the userspace. The userspace then use this array and build
the acl structure. Linux native NFSv4acl work done by
Andreas Gruenbacher on the other hand provided an acl struct
to the userspace. Since both the implementation used NFSv4
acl format it was decided to rename non upstream implementation as
rich-acl even though the acl model is NFSv4.

Rich-acl also adds some exception to the NFSv4 specified 
access rules. The access rules are modified in a way that
make sense in posix environment. For example with patches applied

      a) we always allow read attributes
      b) we always allow read acl.
      c) execute doesn't imply read.

That implies even if the file system object have acl values that
deny read attribute access, local file system still allows read
attributes access to make sure we don't break posix semantics. This
gives an opportunity for nfsd to use the attribute value and
deny read attribute access as per NFSv4 RFC

Patches are done in way that changes done by me are kept
as separate patches. This make sure I don't end up breaking
the access check algorithm done by Andreas Gruenbacher. This also
helps in collecting review feedback on some of the changes done
by me in the access check algorithm. Before merging this upstream
most of these patches have to folded back into relevant patches.

Userspace changes needed for acl tools can be found at
http://git.kernel.org/?p=fs/acl/kvaneesh/acl.git;a=summary
I have updated getfacl to print rich-acl format if rich-acl is
enabled. Only Ext4 is updated to support the new acl format. To
enable rich-acl format one should use tune2fs to enabled the
richacl file system feature. The relevant patches can be found
at http://www.kernel.org/pub/linux/kernel/people/kvaneesh/richaclv2/e2fsprogs/

NFSD is also updated to save and read richacl format if the local
file system supports the new acl format.

git repo for the kernel change is at
http://git.kernel.org/?p=linux/kernel/git/kvaneesh/linux-richacl.git;a=summary

git://git.kernel.org/pub/scm/linux/kernel/git/kvaneesh/linux-richacl.git for-upstream

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html