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
