On Wed, Feb 10, 2010 at 6:45 PM, Paul B. Henson <hen...@acm.org> wrote:
>
> We have an open bug which results in new directories created over NFSv4
> from a linux client having the wrong group ownership. While waiting for a
> patch to resolve the issue, we have a script running hourly on the server
> which finds directories owned by the wrong group and fixes them.
>
> One of our users complained that the ACL's on some of their content were
> broken, and upon investigation we determined /usr/bin/chgrp is breaking
> them:
>
> drwxrws--x+ 2 root iit_webdev 2 Feb 10 16:29 testdir
> owner@:rwxpdDaARWcC--:-di---:allow
> owner@:rwxpdDaARWcC--:------:allow
> group@:rwxpdDaARWc---:-di---:allow
> group@:rwxpdDaARWc---:------:allow
> group:iit_webdev-admin:rwxpdDaARWcC--:-di---:allow
> group:iit_webdev-admin:rwxpdDaARWcC--:------:allow
> everyone@:--x---a-R-c---:-di---:allow
> everyone@:--x---a-R-c---:------:allow
> owner@:rwxpdDaARWcC--:f-i---:allow
> group@:rwxpdDaARWc---:f-i---:allow
> group:iit_webdev-admin:rwxpdDaARWcC--:f-i---:allow
> everyone@:--------------:f-i---:allow
>
> # chgrp iit testdir
>
> drwxrws--x+ 2 root iit 2 Feb 10 16:29 testdir
> owner@:rwxpdDaARWcC--:-di---:allow
> owner@:----dDaARWcC--:------:allow
> group@:rwxpdDaARWc---:-di---:allow
> group@:----dDaARWc---:------:allow
> group:iit_webdev-admin:rwxpdDaARWcC--:-di---:allow
> group:iit_webdev-admin:rwxpdDaARWcC--:------:allow
> everyone@:--x---a-R-c---:-di---:allow
> everyone@:------a-R-c---:------:allow
> owner@:rwxpdDaARWcC--:f-i---:allow
> group@:rwxpdDaARWc---:f-i---:allow
> group:iit_webdev-admin:rwxpdDaARWcC--:f-i---:allow
> everyone@:--------------:f-i---:allow
> owner@:--------------:------:deny
> owner@:rwxp---A-W-Co-:------:allow
> group@:--------------:------:deny
> group@:rwxp----------:------:allow
> everyone@:rw-p---A-W-Co-:------:deny
> everyone@:--x---a-R-c--s:------:allow
>
> Sure enough, per truss:
>
> chmod("testdir", 02771) = 0
>
> Looking at the chgrp man page:
>
> Unless chgrp is invoked by a process with appropriate
> privileges, the set-user-ID and set-group-ID bits of a regu-
> lar file will be cleared upon successful completion; the
> set-user-ID and set-group-ID bits of other file types may be
> cleared.
>
> Well, I'm running the chgrp as *root*, and it's not *clearing* the existing
> setgid bit on the directory, it's *adding* it when it's already there. Why?
> It seems completely unnecessary and **breaks the ACL**.
>
> This is yet another instance of the general problem I posted about
> yesterday:
>
> http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg34588.html
>
> to which I have so far received no comments (Dozens of people can spend
> over a week arguing about the cost effectiveness of Sun branded storage ;),
> and not a single person is interested in an endemic ACL problem?).
>
> I was completely unsuccessful at getting samba under Solaris 10 to stop
> gratuitously chmod()'ing stuff, so I ended up preloading a shared library
> overriding the chmod call with a noop. Which works perfectly, and results
> in exactly the behavior I need. But it's not really feasible to run around
> and tweak every little binary around (preload a shared library to stop
> chgrp from breaking ACL's too?), which is why I think it would be an
> excellent feature to let the underlying operating system deal with it --
> hence aclmode ignore/deny...
I believe the problem is that chgrp is not ACL aware. I suspect that
zfs is interpreting the group ACLs and adjusting the mode value
accordingly to try to indicate the 'preserve owner/group on new file'
semantics with the old permissions, however it sounds like it's not a
symmetric operation -- if chgrp sees a directory with suid or sgid
set, it does chown(file, original_mode & ~(S_IFMT)), when it should
probably be more careful if ACLs are present.
I do think the default aclmode and aclinherit settings are unintuitive
and quite surprising (I'd almost argue flat out wrong). I've found
setting aclmode and aclinherit to passthrough saves what little hair I
have left. If you haven't tried that already, might want to see if
that helps any.
<rant type="mini">
My experience (perhaps others will have different experiences) is that
due to the added complexity and administrative overhead, ACLs are used
when it's absolutely necessary -- i.e. you have something that due to
it's nature must have very explicit and precise access control.
Things like payroll, financial, or other HR data for example. The
last thing I want is the system going behind my back and silently
modifying the permissions I'm trying to set, and leaving directories
and files with permissions other than what was set (which is what you
get today with the defaults). While testing of course will reveal
when this is an issue, it increases the probability of sensitive data
being incorrectly disclosed, which is why I think it's a horrible
default.
</rant>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
