I'm currently prototyping a Solaris file server that will dish out user
home directories and group project directories via NFSv4 and Samba.
I have samba configured and integrated into our local active directory,
with ACL mapping working. I'm a little confused as to the behavior of the
ZFS ACL though.
on a brand-new filesystem, touching a file results in:
-rw-r--r-- 1 root csupomona 0 Mar 12 14:16 test
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:-wxp----------:------:deny
group@:r-------------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
Why does ZFS include deny entries in the default ACL? Based on my
understanding of ACL processing, the effective permissions would be exactly
the same without them. It's particularly annoying when using Samba, as
Windows expects all deny entries to be at the beginning of the list, and
accessing the ACL from Windows results in a warning message and reordering
of the ACL.
I tried explicitly changing the ACL to something simpler:
-rw-r--r-- 1 root csupomona 0 Mar 12 14:16 test
owner@:rw-p---A-W-Co-:------:allow
group@:r-------------:------:allow
everyone@:r-----a-R-c--s:------:allow
This has the exact same effective permissions, but is easier on the eyes
and to visually parse, plus interacts with Windows better.
However, any interaction with the mode bits (for example, chmod g+w)
results in a much more complicated ACL again including unnecessary deny
components:
-rw-rw-r--+ 1 root csupomona 0 Mar 12 14:16 test
owner@:-------A-W-Co-:------:allow
group@:--------------:------:allow
everyone@:------a-R-c--s:------:allow
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:--x-----------:------:deny
group@:rw-p----------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
The ACL now has three entries each for owner, group, and everyone. My
original simple ACL has been turned into something unnecessarily
complicated, and no longer meeting the standard for a Windows ACL.
I tried setting aclmode to passthrough in the hopes that would prevent ACL
munging, but no such luck.
I also experimented with configuring an initial ACL on the home directory
with defined inherited permissions for new files and subdirectories:
owner@:rwxp---A-W-C--:-d----:allow
owner@:rw-p---A-W-C--:f-i---:allow
group@:--x-----------:-d----:allow
group@:--------------:f-i---:allow
everyone@:--x-----------:-d----:allow
everyone@:--------------:f-i---:allow
Intuitively, I would have expected a new file created in this directory
to have permissions such as:
owner@:rw-p---A-W-C--:------:allow
group@:--------------:------:allow
everyone@:--------------:------:allow
Instead, a new file showed up as:
owner@:-------A-W----:------:allow
group@:--------------:------:allow
everyone@:--------------:------:allow
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:-wxp----------:------:deny
group@:r-------------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
Again, a much more complicated ACL than necessary, including unwanted deny
entries, and group/other readability. I think the readability came from the
umask of 022, but given explicitly defined inherited ACLs I don't think
umask should have even been consulted.
Again based on my explicitly configured inheritable ACL, I would have
expected a new directory to look like:
owner@:rwxp---A-W-C--:-d----:allow
owner@:rw-p---A-W-C--:f-i---:allow
group@:--x-----------:-d----:allow
group@:--------------:f-i---:allow
everyone@:--x-----------:-d----:allow
everyone@:--------------:f-i---:allow
Instead I got:
owner@:rwxp---A-W-C--:-di---:allow
owner@:-------A-W----:------:allow
owner@:rw-p---A-W----:f-i---:allow
group@:--x-----------:-di---:allow
group@:--------------:------:allow
group@:--------------:f-i---:allow
everyone@:--x-----------:-di---:allow
everyone@:--------------:------:allow
everyone@:--------------:f-i---:allow
owner@:--------------:------:deny
owner@:rwxp---A-W-Co-:------:allow
group@:-w-p----------:------:deny
group@:r-x-----------:------:allow
everyone@:-w-p---A-W-Co-:------:deny
everyone@:r-x---a-R-c--s:------:allow
I'm not even sure what to make of this. It looks like the directory
inheritable components got inherited both as effective permissions with the
inherit flag intact, along with an additional copy of the exact same
permissions without the flag? And more unnecessary deny entries :(.
I had very high hopes for ACLs under ZFS; the inclusion of the NFSv4 ACL as
the native filesystem ACL seemed like it would be perfect for sharing
between Unix system and Windows systems.
Unfortunately, from initial review it looks like the ACL situation is much
more complicated than I would have liked.
Is there anyway to get ZFS to not overly complicate the ACLs?
On another note, a question regarding the attributes aclinherit and
aclmode. It seems in an environment with explicitly defined ACLs, the best
setting for those would be passthrough. I'm not sure why you would want
explicitly defined ACLs to be munged?
In particular, consider the example of a project directory where the
project administration group should have full control over all files
created in that directory regardless of owner (including the ACL). With the
default "secure" setting, this is not achievable.
For the aclmode setting, the default groupmask seems intended to to emulate
the behavior of the POSIX mask_obj. I always hated that, I would have hoped
ZFS as a brand-new filesystem with native ACLs from the beginning would
have taken the opportunity not to include such kludges, or at least not
make them the default.
I am inclined to configure both of these settings to be passthrough. Is
there any scenario I am not thinking of (particularly given one of them is
called "secure"; which gives one a feeling that changing it would be
"insecure") that would make such a setting problematic?
Thanks for any commentary...
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | [EMAIL PROTECTED]
California State Polytechnic University | Pomona CA 91768
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
