CC'ed to security-disc...@opensolaris.org
-- richard
On Feb 10, 2010, at 4:45 PM, Paul B. Henson 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...
>
>
> --
> Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst | hen...@csupomona.edu
> California State Polytechnic University | Pomona CA 91768
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
