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 at 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 | henson at csupomona.edu
California State Polytechnic University | Pomona CA 91768
CC''ed to security-discuss at 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 at 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 | henson at csupomona.edu > California State Polytechnic University | Pomona CA 91768 > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Wed, Feb 10, 2010 at 6:45 PM, Paul B. Henson <henson at 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 at 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>
On Wed, 10 Feb 2010, Jason King wrote:> 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.The non-access control parts of the mode bits (suid/sgid et al) aren''t part of the acl (and can''t be represented by one), I haven''t looked at the internal details, but even though zfs is a "pure acl" filesystem those bits are presumably stored differently. In an implementation like I''m looking for, where legacy chmod is either ignored or denied for access control, manipulating the other parts would still need to work. In this case, it''s not even like chgrp is trying to remove the sgid bit. It''s redundantly adding it when it''s already there. I''ve opened a bug; while I haven''t gotten a response yet I''m guessing they''ll eventually fix it. Which is fine for that specific instance of the general "unexpected chmod assassinates acl, film at 11" problem, it doesn''t address all of the other unknown problems not yet noticed. The only way to effectively address undesirable acl destruction by chmod is at the filesystem level, by allowing the user to disable it.> I do think the default aclmode and aclinherit settings are unintuitive > and quite surprising (I''d almost argue flat out wrong).I actually wouldn''t necessarily agree; the defaults are geared towards making zfs behave like a typical unix filesystem, preserving POSIX compliance and making sure legacy apps work as expected. That''s fine as a default, but the ability to make zfs actually functional as a pure acl environment should be available as an option.> 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.I did that from day 1 :)... I''m happy at this point with aclinherit (barring one minor tweak to passthrough-x that''s already had an approved fasttrack and is just waiting for opensolaris 3/10 to get released and the gate reopened for changes), if I could just get some aclmode enhancements I think we''d be set.> 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.NFSv4 ACL''s are ridiculously overcomplicated for the end user; but that''s what pretty web gui''s are for ;). We actually have one of those, allowing end users to easily control access to their files, and it would be working great, other than that every time I turn around the ACL''s are broken by something or another :(.> 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).Ditto. I put that acl there for a reason, and I don''t want anything trying to treat it like legacy mode bits. zfs is a great filesystem, and the CIFS compatible NFSv4 ACL''s provide great potential for cross platform interoperability, but despite being a pure acl filesystem I don''t think there''s any feasible way at this point to allow access via NFSv4 or local shell and not break acl''s one way or another. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768
On 2/10/2010 9:36 PM, Jason King wrote:> <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> >My experience with ACLs is that they suck dead diseased rats through a straw and I wish I could turn them off. So far as I can see, they cause endless confusion, make things not work right, break all the basic expectations about how protections work, and don''t actually give me any functionally important benefits (they let me use fewer directories sometimes, but only at the cost of grotesque confusion). What I would dearly love is an option to disable all ACL suppport. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
On Wed, 10 Feb 2010, David Dyer-Bennet wrote:> My experience with ACLs is that they suck dead diseased rats through a > straw and I wish I could turn them off.That seems overly harsh ;).> What I would dearly love is an option to disable all ACL suppport.If you never explicitly use ACL''s on zfs, and only ever manipulate permissions with legacy chmod mode bits, I believe zfs will behave like ACL''s don''t exist. For what scenario is the existance of ACL''s resulting in failure for use cases that don''t apply them? -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768