Codestin Search App

Rich access control lists

Posted Oct 21, 2015 23:06 UTC (Wed) by fandingo (guest, #67019)
In reply to: Rich access control lists by daniels
Parent article: Rich access control lists

> Because userspace will expect that changing a POSIX mode to a certain value through chmod(2) will have the effect of masking access to that particular uid/gid/everyone, for the specified mode, regardless of which filesystem is mounted.

There's absolutely no reason why this needs to be done in POSIX bits, though. If the file/file-system is Richacl enabled, translate the chmod(2) (or the variety of other POSIX ACL syscalls) to Richacl -- solely operating on the Richacl xattrs. The POSIX bits, then, are just a virtual representation of Richacl xattrs.

I'd argue that we'd be far better off switching to native Richacl solely. Continue to support traditional POSIX ACL syscalls, but they all get translated to Richacl for both policy evaluation and storage. (I'm only advocating for this strategy due to the agreement of making Richacl a compatibility-breaking filesystem feature.) Richacl offers a superset of features from POSIX and Linux ACLs; it makes more sense to stop duplicating information, and at least for kernel internals, entirely switch to the most expressive system.

to post comments

Rich access control lists

Posted Oct 22, 2015 0:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> I'd argue that we'd be far better off switching to native Richacl solely. Continue to support traditional POSIX ACL syscalls, but they all get translated to Richacl for both policy evaluation and storage.
I vomited a little. Personally, I'm not against some FS-specific ACL perversions. Just wash your hands after using it.

But forcing your insanity on others? No way.

Rich access control lists

Posted Oct 22, 2015 0:59 UTC (Thu) by fandingo (guest, #67019) [Link] (2 responses)

What's the insanity? If you don't want to express anything beyond POSIX ACLs, it's nothing more than a storing data in a different format. Plus, it's not some brand-new format; it's using well-tested xattrs.

Rich access control lists

Posted Oct 22, 2015 1:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> What's the insanity? If you don't want to express anything beyond POSIX ACLs, it's nothing more than a storing data in a different format.
And a translation layer. And significant additional overhead (xattrs are SLOW compared to the fastpath).

So no, it's definitely not something I'd want to ever see close to my systems.

Rich access control lists

Posted Oct 23, 2015 19:59 UTC (Fri) by nevyn (guest, #33129) [Link]

Speed should override any other concerns here, look at the time of a large rsync on files with just modes vs. those which have xattrs or ACLs.

Rich access control lists

Posted Oct 22, 2015 2:05 UTC (Thu) by bfields (subscriber, #19510) [Link]

There's absolutely no reason why this needs to be done in POSIX bits, though. If the file/file-system is Richacl enabled, translate the chmod(2) (or the variety of other POSIX ACL syscalls) to Richacl -- solely operating on the Richacl xattrs. The POSIX bits, then, are just a virtual representation of Richacl xattrs.

Note that POSIX ACLs are quite a bit more complicated than mode bits, I wouldn't lump them together.

You can think of Andreas's patches as already implementing mode bits on top of Richacls, if you'd like. I'm not sure exactly what your complaint is there.

Going further and implementing full POSIX ACLs on top of Richacls would also be possible, but quite complicated, and I think Andreas's choice not to do that is reasonable.