illumos gate

(by Albert)

According to zfs(1M) description of the aclinherit property: "The property value restricted (the default) removes the write_acl and write_owner permissions when the ACL entry is inherited."

However, when aclinherit=restricted is set for a dataset, we apply similar behaviour to aclmode=groupmask when calculating the inherited permissions, which drops any ALLOW ACL entries not present in the UNIX permissions for the group (group@).

This was reported for FreeBSD, with an example:
http://lists.freebsd.org/pipermail/freebsd-fs/2013-August/018057.html

This was already present after the aclmode removal and may reflect a change in aclinherit=restricted semantics that we don't have documented, although I'm not sure what purpose it serves.

When I restored aclmode I preserved this behaviour and actually corrected a bug:
https://www.illumos.org/issues/664

It is unclear what the proper semantics should be.

Steps to Reproduce:
- Set aclmode=restricted on a dataset.
- Add ALLOW ACEs (for something other than owner@/group@/everyone@, such as a specific user or group) with file_inherit or directory_inherit and unset some corresponding permissions in the ACE for group@ on a parent directory.
- Possibly also set umask, if using a shell, to restrict group perms (not sure if this also causes the problem, perhaps worth trying separately).
- Create new files or directories in the parent directory and check their ACLs.

Expected Results:
ACLs should contain the original inherited ALLOW ACEs, not masked by group perms. Only write_acl and write_owner should be dropped as documented.

Actual Results:
Permissions not present in group@ will vanish in the newly created file.