[illumos-Developer] Heads-up: Resurrect the ZFS "aclmode" property
gordon.w.ross at gmail.com
Sat May 14 06:54:33 PDT 2011
The code changes to implement the proposal were integrated today:
user: Albert Lee <trisk at nexenta.com>
date: Sat May 14 00:29:13 2011 -0400
742 Resurrect the ZFS "aclmode" property
664 Umask masking "deny" ACL entries.
279 Bug in the new ACL (post-PSARC/2010/029) semantics
Reviewed by: Aram Hăvărneanu <aram at nexenta.com>
Reviewed by: Gordon Ross <gwr at nexenta.com>
Reviewed by: Robert Gordon <rbg at openrbg.com>
Reviewed by: Mark.Maybee at oracle.com
Approved by: Garrett D'Amore <garrett at nexenta.com>
Thanks to Albert Lee for doing all the investigation of the
PSARC/2010/029 changes, and coming up with changes
to back out parts of that without breaking other things...
(My role in this was merely advisory.)
Thanks also to various ZFS folks (who apparently prefer to
not make noise publicly, or they would have done already).
We've had similar changes in NexentaStor for months,
and I can say that the return of aclmode was much better
received than was the previous removal! :)
See the updated zfs(1m) man page for the updated
description of the aclmode property. (Or the RFC
from early March, quoted below.)
On Sat, Feb 26, 2011 at 10:16 PM, Gordon Ross <gordon.w.ross at gmail.com> wrote:
> This is a request for comment (RFC), in the spirit of the
> (now defunct) Sun PARC request process.
> Executive Summary:
> The case (PSARC/2010/029 - Improved ACL interoperability)
> simplified ACL handling in ZFS, but at the same time removed
> the "aclmode" property. That removal has proven to be very
> inconvenient in the field. This proposal resurrects the
> "aclmode" property, with some changes to better fit within
> the post-PSARC/2010/029 design.
> There have been numerous customers complaints like:
> - What happened to aclmode? I want aclmode=passthrough
> - I don't want NFS setattr from Linux to replace my ACLs.
> - I don't want chmod to destroy my ACLs
> They have a point. PSARC/2010/029 removed control over
> what setattr does with ACLs, leaving some customers with
> no convenient way to make data remain accessible from both
> NFS and CIFS clients.
> There is an extensive discussion of this on zfs-discuss:
> (and other threads - search for "aclmode")
> This proposal reinstates handling of an "aclmode" property,
> but with a different default and updated semantics, to
> better integrate with post-PSARC/2010/029 handling of ACLs.
> The settings for "aclmode" are the same as they were before
> the property was removed, but the semantics of "groupmask"
> are now as described in PSARC/2010/029, so "groupmask" will
> no longer do ACE splitting. The "ACE trimming" described for
> "aclmode=groupmask" will be exactly what the current code
> does when the aclinherit property is set to "restricted". That
> ACE trimming logic will remain unchanged. This proposal just
> makes the chmod ACE trimming optional.
> The default value for "aclmode" was originally "groupmask".
> Many find that convenient; some argue it's a security flaw.
> The reinstated "aclmode" will have "discard" as its default,
> which continues current system behavior. (least surprise)
>  In the thread "zfs proerty aclmode gone in 147?"
> some argue that if "chmod 700" does anything other than
> replace the ACL with a trivial one, it's a security bug.
> For those people, aclmode=discard is the right setting.
> Others take a different view, and want NFS setattr to
> avoid destroying their carefully constructed ACLs.
> We should provide mechanism, not policy here.
> Man Page diffs
> +aclmode=discard | groupmask | passthrough
> +Controls how an ACL is modified during chmod(2). A file system with
> +an aclmode property of discard (the default) deletes all ACL entries
> +that do not represent the mode of the file. An aclmode property of
> +groupmask reduces permissions granted in all "allow" entries found in
> +the ACL. The permissions are reduced such that they are no greater
> +than the given group permission bits. A file system with an aclmode
> +property of passthrough indicates that no changes are made to the ACL
> +other than creating or updating the necessary ACL entries to represent
> +the new mode of the file or directory.
More information about the Developer