Hi, I recently installed oi147 and I noticed that the property aclmode is no longer present and has been nuked from my volumes when I imported a pool that had been previously hosted on a OSol 134 system. Anybody know, if that''s a bug or had aclmode been removed on purpose? Seems that my Macs have issues with aclmode being nuked. E.g. users can create new files/folders on a netatalk-shared volume, but they can''t rename the newly created items. Cheers, budy -- This message posted from opensolaris.org
Hi Stephan, Yes, the aclmode property was removed, but we''re not sure how this change is impacting your users. Can you provide their existing ACL information and we''ll take a look. Thanks, Cindy On 09/24/10 01:41, Stephan Budach wrote:> Hi, > > I recently installed oi147 and I noticed that the property aclmode is no longer present and has been nuked from my volumes when I imported a pool that had been previously hosted on a OSol 134 system. > > Anybody know, if that''s a bug or had aclmode been removed on purpose? > Seems that my Macs have issues with aclmode being nuked. E.g. users can create new files/folders on a netatalk-shared volume, but they can''t rename the newly created items. > > Cheers, > budy
Hi Cindy, thanks for clarifying that. Basically, the problem seems to lie within the Netatalk afpd, which is what I use for our Mac clients. For some reason, putting a new file or folder on a Netatalk-ZFS share, don''t pulls the ACEs that this new object should inherit from its parent. I have already contacted the main developer of Netatalk and he will get into this in the near future. So, for the time being, I switched back to snv134. I must admit though, that the new ACL/ACE model in 147 is really nice and slick. Cheers, budy -- This message posted from opensolaris.org
> I must admit though, that the new ACL/ACE model in > 147 is really nice and slick.Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just braindead. chmod resulting in ACLs being discarded is a bizarre design decision. -- This message posted from opensolaris.org
On Sat, 25 Sep 2010, [iso-8859-1] Ralph B?hme wrote:> Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just > braindead. chmod resulting in ACLs being discarded is a bizarre design > decision.Agreed. What''s the point of ACLs that disappear? Sun didn''t want to fix acl/chmod interaction, maybe one of the new OpenSolaris forks will do the right thing... -- 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 Tue, Sep 28, 2010 at 12:18:49PM -0700, Paul B. Henson wrote:> On Sat, 25 Sep 2010, [iso-8859-1] Ralph B?hme wrote: > > > Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just > > braindead. chmod resulting in ACLs being discarded is a bizarre design > > decision. > > Agreed. What''s the point of ACLs that disappear? Sun didn''t want to fix > acl/chmod interaction, maybe one of the new OpenSolaris forks will do the > right thing...I''ve researched this enough (mainly by reading most of the ~240 or so relevant zfs-discuss posts and several bug reports) to conclude the following: - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in DENY ACEs are enormously confusing to users. - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in DENY ACEs are susceptible to ACL re-ordering when modified from Windows clients -which insist on DENY ACEs first-, leading to much confusion. - This all gets more confusing when hand-crafted ZFS inherittable ACEs are mixed with chmod(2)s with the old aclmode=groupmask setting. The old aclmode=passthrough setting was dangerous and had to be removed, period. (Doing chmod(600) would not necessarily deny other users/groups access -- that''s very, very broken.) That only leaves aclmode=discard and some variant of aclmode=groupmask that is less confusing. But here''s the thing: the only time that groupmasking results in sensible ACLs is when it doesn''t require DENY ACEs, which in turn is only when mode_t bits and/or POSIX ACLs are strictly non-increasing (e.g., 777, 775, 771, 750, 755, 751, etcetera, would all be OK, but 757 would not be). The problem then is this: if you have an aclmode setting that sometimes groupmasks and sometimes discards... that''ll be confusing too! So one might wonder: can one determine user intent from the ACL prior to the change and the mode/POSIX ACL being set, and then edit the ZFS ACL in a way that approximates the user''s intention? I believe that would be possible, but risky too, as the need to avoid DENY ACEs (see Windows issue) would often result in more permissive ACLs than the user actually intended. Taken altogether I believe that aclmode=discard is the simplest setting to explain and understand. Perhaps eventually a variant of groupmasking will be developed that is also simple to explain and understand, but right now I very much doubt it (and yes, I''ve tried myself). But much better than that would be if we just move to a ZFS ACL world (which, among other things, means we''ll need a simple libc API for editing ACLs). Note, incidentally, that there''s a groupmasking behavior left in ZFS at this time: on create of objects in directories with inherittable ACEs and with aclinherit=passthrough*. Nico --
On Tue, 28 Sep 2010, Nicolas Williams wrote:> I''ve researched this enough (mainly by reading most of the ~240 or so > relevant zfs-discuss posts and several bug reports)And I think some fair fraction of those posts were from me, so I''ll try not to start rehashing old discussions ;).> That only leaves aclmode=discard and some variant of aclmode=groupmask > that is less confusing.Or aclmode=deny, which is pretty simple, not very confusing, and basically the only paradigm that will prevent chmod from breaking your ACL.> So one might wonder: can one determine user intent from the ACL prior to > the change and the mode/POSIX ACL being set, and then edit the ZFS ACL > in a way that approximates the user''s intention?You''re assuming the user is intentionally executing the chmod, or even *aware* of it happening. Probably at least 99% of the chmod calls executed on a file with a ZFS ACL at my site are the result of non-ACL aware legacy apps being stupid. In which case the *user* intent to to *leave the damn ACL alone* :)...> But much better than that would be if we just move to a ZFS ACL world > (which, among other things, means we''ll need a simple libc API for > editing ACLs).Yep. And a good first step towards an ACL world would be providing a way to keep chmod from destroying ACLs in the current world... -- 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 Tue, Sep 28, 2010 at 02:03:30PM -0700, Paul B. Henson wrote:> On Tue, 28 Sep 2010, Nicolas Williams wrote: > > > I''ve researched this enough (mainly by reading most of the ~240 or so > > relevant zfs-discuss posts and several bug reports) > > And I think some fair fraction of those posts were from me, so I''ll try not > to start rehashing old discussions ;).:)> > That only leaves aclmode=discard and some variant of aclmode=groupmask > > that is less confusing. > > Or aclmode=deny, which is pretty simple, not very confusing, and basically > the only paradigm that will prevent chmod from breaking your ACL.That can potentially render many applications unusable.> > So one might wonder: can one determine user intent from the ACL prior to > > the change and the mode/POSIX ACL being set, and then edit the ZFS ACL > > in a way that approximates the user''s intention? > > You''re assuming the user is intentionally executing the chmod, or even > *aware* of it happening. Probably at least 99% of the chmod calls executed > on a file with a ZFS ACL at my site are the result of non-ACL aware legacy > apps being stupid. In which case the *user* intent to to *leave the damn > ACL alone* :)...But that''s not really clear. The user is running some app. The app does some chmod(2)ing on behalf of the user. The user may also use chmod(1). Now what? Suppose you make chmod(1) not use chomd(2), so as to be able to say that all chmod(2) calls are made by "apps", not the user. But then what about scripts that use chmod(1)? Basically, I think intent can be estimated in some cases, and combined with some simplifying assumptions (that will sometimes be wrong), such as "security entities are all distinct, non-overlapping" (as a way to minimize the number of DENY ACEs needed) can yield a groupmasking algorithm that doesn''t suck. However, it''d still not be easy to explain, and it''d still result in surprises (since the above assumption will often be wrong, leading to more permissive ACLs than the user might have intended!). Seems like a lot of work for little gain, and high support call generation rate.> > But much better than that would be if we just move to a ZFS ACL world > > (which, among other things, means we''ll need a simple libc API for > > editing ACLs). > > Yep. And a good first step towards an ACL world would be providing a way to > keep chmod from destroying ACLs in the current world...I don''t think that will happen... Nico --
On 09/29/10 09:38 AM, Nicolas Williams wrote:> I''ve researched this enough (mainly by reading most of the ~240 or so > relevant zfs-discuss posts and several bug reports) to conclude the > following: > > - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in > DENY ACEs are enormously confusing to users. > > - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in > DENY ACEs are susceptible to ACL re-ordering when modified from > Windows clients -which insist on DENY ACEs first-, leading to much > confusion. > > - This all gets more confusing when hand-crafted ZFS inherittable ACEs > are mixed with chmod(2)s with the old aclmode=groupmask setting. > > The old aclmode=passthrough setting was dangerous and had to be removed, > period. (Doing chmod(600) would not necessarily deny other users/groups > access -- that''s very, very broken.) > > That only leaves aclmode=discard and some variant of aclmode=groupmask > that is less confusing. > > But here''s the thing: the only time that groupmasking results in > sensible ACLs is when it doesn''t require DENY ACEs, which in turn is > only when mode_t bits and/or POSIX ACLs are strictly non-increasing > (e.g., 777, 775, 771, 750, 755, 751, etcetera, would all be OK, but 757 > would not be). > > The problem then is this: if you have an aclmode setting that sometimes > groupmasks and sometimes discards... that''ll be confusing too! > > So one might wonder: can one determine user intent from the ACL prior to > the change and the mode/POSIX ACL being set, and then edit the ZFS ACL > in a way that approximates the user''s intention? I believe that would > be possible, but risky too, as the need to avoid DENY ACEs (see Windows > issue) would often result in more permissive ACLs than the user actually > intended. > > Taken altogether I believe that aclmode=discard is the simplest setting > to explain and understand. Perhaps eventually a variant of groupmasking > will be developed that is also simple to explain and understand, but > right now I very much doubt it (and yes, I''ve tried myself). But much > better than that would be if we just move to a ZFS ACL world (which, > among other things, means we''ll need a simple libc API for editing > ACLs). > > Note, incidentally, that there''s a groupmasking behavior left in ZFS at > this time: on create of objects in directories with inherittable ACEs > and with aclinherit=passthrough*. > >Based on my own research, experimentation and client requests, I agree with all of the above. I have be re-ordering and cleaning (deny) ACEs for one client for a couple of years now and we haven''t seen any user complaints. In their environment, all ACLs started life as POSIX (from a Solaris 9 host) and with the benefit of hindsight, I would have cleaned them up on import to ZFS rather than simply reading the POSIX ACL and writing back to ZFS. -- Ian.
On Wed, Sep 29, 2010 at 10:15:32AM +1300, Ian Collins wrote:> Based on my own research, experimentation and client requests, I > agree with all of the above.Good to know.> I have be re-ordering and cleaning (deny) ACEs for one client for a > couple of years now and we haven''t seen any user complaints. In > their environment, all ACLs started life as POSIX (from a Solaris 9 > host) and with the benefit of hindsight, I would have cleaned them > up on import to ZFS rather than simply reading the POSIX ACL and > writing back to ZFS.The saddest scenario would be when you have to interop with NFSv3 clients whose users (or their apps) are POSIX ACL happy, but whose files also need to be accessible from NFSv4, SMB, and local ZPL clients where the users (possibly the same users, or their apps) are also ZFS ACL happy. Particularly if you also have Windows clients and the users edit file ACLs there too! Thankfully this is relatively easy to avoid because: apps that edit ACLs are few and far between, thus easy to remediate, and users should not really be manually setting POSIX Draft and ZFS/NFSv4/SMB ACLs on the same files. Nico --
On 9/28/2010 2:13 PM, Nicolas Williams wrote: >> Or aclmode=deny, which is pretty simple, not very confusing, and basically >> the only paradigm that will prevent chmod from breaking your ACL. > > That can potentially render many applications unusable. Yes. Which is why it obviously wouldn''t be the default, and probably highly inadvisable for a root pool. But for a data file system whose usage model demands pure ACLs, which you want to make sure are never discarded, why shouldn''t it be available? > Suppose you make chmod(1) not use chomd(2) Now you''re just being pedantic ;). > But then what about scripts that use chmod(1)? The user/administrator who intentionally elected to implement the nondefault option clearly cares more about not losing their ACLs than about some random scripts failing. It seems the vast majority of arguments against implementing this option have been of the form "bad thing <foo> might happen, and the user would be <confused|angry|sad>". It''s my foot, I don''t appreciate people trying to prevent me from shooting it, particularly if there happens to be some poisonous animal sitting on it that is the actual target :). The version of samba bundled with Solaris 10 seems to insist on chmod''ing stuff. I''ve tried all of the various options that should disable mapping to mode bits, yet still randomly when people copy files in over CIFS, ACL''s get destroyed by chmod interaction and access control is broken. I finally ended up having to preload a shared object that overrides chmod and turns it into a nullop. This would have been the perfect scenario for aclmode=ignore, I don''t care what samba may or may not want to do, if the file has an ACL I don''t want it mucked with. So why exactly shouldn''t I have that functionality available for this scenario? > Seems like a lot of work for little gain, and high > support call generation rate. Yup. I agree that any attempt to impose sanity on the application of chmod onto an object with an ACL by somehow combining the existing ACL with the new mode is pointless. It seems that there are three reasonable options when attempting to update the permissions of an object with an ACL via the legacy chmod call -- just discard the ACL, deny the attempted change, or ignore it. >> Yep. And a good first step towards an ACL world would be providing a way to >> keep chmod from destroying ACLs in the current world... > > I don''t think that will happen... Not in the official Oracle version of Solaris, but given Oracle''s choices it seems that''s not going to be the only version of the OpenSolaris code base floating around. Maybe the Illumos community will be a little more open to providing users with functionality that could be extremely valuable in some scenarios and doesn''t hurt anybody who doesn''t intentionally choose to use it... I said before I''d be willing to implement it myself if there was some reasonable likelihood it would be accepted, once the whole Illumos thing settles down I think I''ll make that offer again and see what happens. -- 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 Tue, Sep 28, 2010 at 12:18:49PM -0700, Paul B. > Henson wrote: > > On Sat, 25 Sep 2010, [iso-8859-1] Ralph B?hme > wrote: > > > > > Darwin ACL model is nice and slick, the new NFSv4 > one in 147 is just > > > braindead. chmod resulting in ACLs being > discarded is a bizarre design > > > decision. > > > > Agreed. What''s the point of ACLs that disappear? > Sun didn''t want to fix > > acl/chmod interaction, maybe one of the new > OpenSolaris forks will do the > > right thing... > > I''ve researched this enough (mainly by reading most > of the ~240 or so > relevant zfs-discuss posts and several bug reports) > to conclude the > following:I''ve researched this by reading the specs for NFSv4, withdrawn draft POSIX 1e and Darwin ACLs, and implemented mapping between them in an UNIX AFP fileserver.> - ACLs derived from POSIX mode_t and/or POSIX Draft > ACLs that result in > DENY ACEs are enormously confusing to users. > - ACLs derived from POSIX mode_t and/or POSIX Draft > ACLs that result in > DENY ACEs are susceptible to ACL re-ordering when > modified from > Windows clients -which insist on DENY ACEs first-, > leading to much > confusion.Imo the approach of intertwinig UNIX mode with ACEs was a bad idea in the first place, but it''s in the spec so of course the implemenatations that follow it must honour it. POSIX 1e do something similar, but my point being here is, that this is not neccessarily the most clever, clean and safe spec. Note that Darwin (OS X) does _not_ do this mumbo-jumbo, so ...> - This all gets more confusing when hand-crafted ZFS > inherittable ACEs > are mixed with chmod(2)s with the old > aclmode=groupmask setting. > The old aclmode=passthrough setting was dangerous and > had to be removed, > period. (Doing chmod(600) would not necessarily deny > other users/groups > access -- that''s very, very broken.)... in Darwin this will not remove any ACL from the object. The Darwin kernel evaluates permissions in a first match paradigm, evaluating the ACL before the mode and it does not intertwine ACL and mode. It''s a slick, clean, easy to understand and safe design. With this model I can stick a ACL to an oject saying "deny unredeemed_hacker everything" and be sure that this ACL will stick there without being removed by any chmod. Fixing one NFSv4 spec ACL design issue by (mapping mode and ACL) by just removing ACLs when the mapping must be done is spec conforming, but imo a bad idea. I haven''t yet really studied the details of this implementation change in 147, so maybe I''m complaining to early. Regards, -r -- This message posted from opensolaris.org
> On 9/28/2010 2:13 PM, Nicolas Williams wrote: > The version of samba bundled with Solaris 10 seems to > insist on > chmod''ing stuff. I''ve tried all of the various > options that should > disable mapping to mode bits, yet still randomly when > people copy files > in over CIFS, ACL''s get destroyed by chmod > interaction and access > control is broken. I finally ended up having to > preload a shared object > that overrides chmod and turns it into a nullop.Oh my! After another re-read of man zfs in onnv135 and the spec for aclmode there, it seems they''ve really removed the only useful setting for aclmode. To circumvent this I''ll probably also have to wrap all chmod(2) calls (in code though, not by preloading like you had to) in my app and turn them into null-ops when performed on a ZFS volume (which my app knows), alongside wrapping all filesystem object creation actions in umask(2) calls in order to get the desired mode. bleah! -- This message posted from opensolaris.org
On Wed, Sep 29, 2010 at 03:44:57AM -0700, Ralph B?hme wrote:> > On 9/28/2010 2:13 PM, Nicolas Williams wrote: > > The version of samba bundled with Solaris 10 seems to > > insist on > > chmod''ing stuff. I''ve tried all of the variousJust in case it''s not clear, I did not write the quoted text. (One can tell from the level of quotation that an attribution is missing and that none of my text was quoted. Nico --
Miles Nordin
2010-Sep-29 20:10 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
>>>>> "rb" == Ralph B?hme <ralph at rsrc.de> writes:rb> The Darwin kernel evaluates permissions in a first rb> match paradigm, evaluating the ACL before the mode well...I think it would be better to AND them together like AFS did. In that case it doesn''t make any difference in which order you do it because AND is commutative. The Darwin method you describe means one might remove permissions with chmod but still have access granted under first-match by the ACL. I just tested, and Darwin does indeed work this way. :( One way to get from NFSv4 to what I want is that you might add EVEN MORE complexity and have ``tagged ACL groups'''': * all the existing ACL tools and NFS/SMB clients targeting the #(null) tag, * traditional ''chmod'' unix permissions targeting the #(unix) tag. * The evaluation within a tag-group is first-match like now, * The result of each tag-group is ANDed together for the final evaluation When accomodating Darwin ACL''s or Windows ACL''s or Linux NFSv4 ACL''s or translated POSIX ACL''s, the result of the imperfect translation can be shoved into a tag-group if it''s unclean. The way I would implement the userspace, tools would display all tag groups if given some new argument, but they would always be incapable of editing any tag group except #(null). Another chroot-like tool would swap a given tag-group for #(null) for all child processes: carton at awabagal:~/bar$ ls -v\# foo -rw-r--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(unix):owner@:execute:deny 1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ chmod A+owner@:write_data:deny foo carton at awabagal:~/bar$ ls -v\# foo -rw-r--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(null):owner@:write_data:deny # 0#(unix):owner@:execute:deny 1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ echo lala > foo -bash: foo: Permission denied carton at awabagal:~/bar$ chpacl baz ls -v\# foo -rw-r--r-- 1 carton carton 0 Sep 29 18:31 foo # 0#root:owner@:write_data:deny <-- #root is what''s mapped to #(null) at boot # 0#(unix):owner@:execute:deny 1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ chpacl ''(null)'' true chpacl: ''(null)'' is reserved. carton at awabagal:~/bar$ chpacl baz chmod A+owner@:read_data:deny foo carton at awabagal:~/bar$ chpacl baz ls -v\# foo -rw-r--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(null):owner@:read_data:deny # 0#root:owner@:write_data:deny # 0#(unix):owner@:execute:deny 1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~bar$ cat foo -bash: foo: Permission denied carton at awabagal:~bar$ chpacl baz cat foo <-- current tagspace is irrelevant to ACL evaluation -bash: foo: Permission denied carton at awabagal:~/bar$ ls -v\# foo -rw-r--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(null):owner@:write_data:deny # 0#baz:owner@:read_data:deny # 0#(unix):owner@:execute:deny 1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ chpacl ''(unix)'' chmod A0=owner@::deny foo carton at awabagal:~/bar$ chpacl ''(unix)'' chmod A1=owner@:execute/read_data/write_data/append_data/write_xattr/write_attributes/write_acl/write_owner:allow foo carton at awabagal:~/bar$ ls -v\# foo <-- subshells of ''chpacl (unix)'' have precise equiv. to current behavior, including exactly the same ''ls -v'' output if you leave off the -#, so pre-taggroups quirky behavior can be quickly restored if some goofy script depends on it -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(null):owner@:write_data:deny # 0#baz:owner@:read_data:deny # 0#(unix):owner@::deny 1#(unix):owner@:execute/read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ chpacl -u bop chmod 644 foo <-- -u flag to map (unix). no magical constant names! carton at awabagal:~/bar$ ls -v\# foo -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(null):owner@:write_data:deny # 0#baz:owner@:read_data:deny # 0#(unix):owner@::deny 1#(unix):owner@:execute/read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow # 0#bop:owner@:execute:deny 1#bop:owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#bop:group@:write_data/append_data/execute:deny 3#bop:group@:read_data:allow 4#bop:everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#bop:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ chpacl -u bop chpacl ''(unix)'' ls -v\# <-- parenthesized names are shortcuts to copy a translation context for (null). currently the only ``translation context'''' is (unix) for permission bits carton at awabagal:~/bar$ ls -v\# foo -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo 0#(null):owner@:execute:deny 1#(null):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(null):group@:write_data/append_data/execute:deny 3#(null):group@:read_data:allow 4#(null):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(null):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow # 0#root:owner@:write_data:deny # 0#baz:owner@:read_data:deny # 0#unix:owner@::deny 1#unix:owner@:execute/read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#unix:group@:write_data/append_data/execute:deny 3#unix:group@:read_data:allow 4#unix:everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#unix:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow # 0#(unix):owner@:execute:deny 1#(unix):owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ ls -l foo -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo carton at awabagal:~/bar$ ./foo -bash: ./foo: Permission denied carton at awabagal:~/bar$ chpacl -u bop ls -l foo -rw-r--r-- 1 carton carton 0 Sep 29 18:31 foo carton at awabagal:~/bar$ ls -v foo -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo 0:owner@:write_data:deny carton at awabagal:~/bar$ chpacl bop chmod A- foo carton at awabagal:~/bar$ chpacl baz chmod A- foo carton at awabagal:~/bar$ chmod A- foo carton at awabagal:~/bar$ ls -v foo -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo carton at awabagal:~/bar$ echo lala > foo carton at awabagal:~/bar$ cat foo lala carton at awabagal:~/bar$ ./foo ./foo: line 1: lala: command not found carton at awabagal:~/bar$ ls -v\# foo -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo # 0#(unix):owner@::deny 1#(unix):owner@:execute/read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ -----8<----- You could perhaps have a ``zoned'''' bit on tag groups as well, which would subdivide taggroup namespaces by subdirectory: if you are in the global zone and say ``chpacl foo chmod -R A- /'''' or set up /etc/user_attr to say ``carton has root-eqivalent permission to alter tagspace #foo'''' then neither would apply to the #foo with zoned=1. If you are inside a zone, then it would apply and modify the ACL''s. One needn''t make any further attempt to separate zone 1 #foo from zone 2 #foo because that can be done by keeping the zoneroots separate, and sometimes it might be appropraite for tagspaces to bleed across zones which remains possible with lofs mounts. I cannot decide what to do with ACL evaluation wrt the zoned bit. One alternative: * ACL evaluation, global or zoned, should always ignore the zoned bit and consider all ACL groups. Another one is: * in the global zone, all ACL groups with the zoned bit set are ignored (allow everything). However, it''s still impossible to chpacl to an ACL group with the zoned bit set. If you want to much around, you would have to: chpacl -z ''tagspace'' chpacl ''tagspace'' command chpacl +z ''tagspace'' * in a zone, all ACL groups are respected regardless of the bit. both have advantages and disadvantages. -----8<----- carton at awabagal:~/bar$ ls -v\# foob -rwxr--r-- 1 carton carton 0 Sep 29 18:31 foo 0z#foob:owner@:write_data:deny # 0#(unix):owner@::deny 1#(unix):owner@:execute/read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2#(unix):group@:write_data/append_data/execute:deny 3#(unix):group@:read_data:allow 4#(unix):everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5#(unix):everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow carton at awabagal:~/bar$ chpacl foob chmod A- foo chpacl: foob: zoned namespace carton at awabagal:~/bar$ pfexec chpacl -z foob carton at awabagal:~/bar$ chpacl foob chmod A- foo carton at awabagal:~/bar$ -----8<----- By default a zone would use the same ''root'' and ''unix'' tagspace as the rest of the system with the zoned bit unset, but if chpacl is used within the zone then it''s implied that the space created should have zoned bit forcibly set. thus, if you apply tagged ACL''s to a file within a zone and then unset the zoned bit on those files'' tag from the global zone, then those ACL groups cannot be changed within the zone at all. The ''chpacl (unix)'' trick still works though, and except for this zoned-bit caveat the use of chpacl is totally unrestricted inside the zone. This is an elegant way that the global zone can enforce inescapable permissions onto the inside zones without reducing the featureset available within the zone. The zoned bit is an attribute of the tagspace on a particular file, so there cannot be a #foob and z#foob tagspace on the same file. Display of the zoned bit by ls -v# is inverted within the zone (sneaky, eh?), except that (contexts) are always presented as lacking the zoned bit even if the underlying tagspace has bit=0 in the global zone, and of course ''chpacl +-z'' is forbidden in a zone. Lastly it should be possible to run ''chpacl'' and ''chpacl -u'' implicitly at zone startup time. The given tagspace could have or lack the zoned bit, doesn''t really matter. Either way, there''s no way within the zone to determine the name of the tagspace you were shoved into except by guessing and probing, so while the name of your assigned tagspace is not fully secret, the fact that you''re in one should not break any future tagspace-dependent script that used to work in the global zone. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100929/41682dbb/attachment-0001.bin>
Nicolas Williams
2010-Sep-29 20:39 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
Keep in mind that Windows lacks a mode_t. We need to interop with Windows. If a Windows user cannot completely change file perms because there''s a mode_t completely out of their reach... they''ll be frustrated. Thus an ACL-and-mode model where both are applied doesn''t work. It''d be nice, but it won''t work. The mode has to be entirely encoded by the ACL. But we can''t resort to interesting encoding tricks as Windows users won''t understand them. Nico --
Ralph Böhme
2010-Sep-29 22:09 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
> Keep in mind that Windows lacks a mode_t. We need to > interop with Windows.Oh my, I see. Another itch to scratch. Now at least Windows users are happy while me and mabye others are not. -r -- This message posted from opensolaris.org
Nicolas Williams
2010-Sep-29 22:21 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
On Wed, Sep 29, 2010 at 03:09:22PM -0700, Ralph B?hme wrote:> > Keep in mind that Windows lacks a mode_t. We need to > > interop with Windows. > > Oh my, I see. Another itch to scratch. Now at least Windows users are > happy while me and mabye others are not.Yes. Pardon me for forgetting to mention this earlier. There''s so many wrinkles here... But this is one of the biggers; I should not have forgotten it. Nico --
Nicolas Williams
2010-Sep-29 22:29 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side (was: zfs proerty aclmode gone in 147?)
On Wed, Sep 29, 2010 at 05:21:51PM -0500, Nicolas Williams wrote:> On Wed, Sep 29, 2010 at 03:09:22PM -0700, Ralph B?hme wrote: > > > Keep in mind that Windows lacks a mode_t. We need to > > > interop with Windows. > > > > Oh my, I see. Another itch to scratch. Now at least Windows users are > > happy while me and mabye others are not. > > Yes. Pardon me for forgetting to mention this earlier. There''s so many > wrinkles here... But this is one of the biggers; I should not haves/biggers/biggest/> forgotten it. > > Nico > -- > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Miles Nordin
2010-Sep-30 18:55 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
>>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes:nw> Keep in mind that Windows lacks a mode_t. We need to interop nw> with Windows. If a Windows user cannot completely change file nw> perms because there''s a mode_t completely out of their nw> reach... they''ll be frustrated. well...AIUI this already works very badly, so keep that in mind, too. In AFS this is handled by most files having 777, and we could do the same if we had an AND-based system. This is both less frustrating and more self-documenting than the current system. In an AND-based system, some unix users will be able to edit the windows permissions with ''chmod A...''. In shops using older unixes where users can only set mode bits, the rule becomes ``enforced permissions are the lesser of what Unix people and Windows people apply.'''' This rule is easy to understand, not frustrating, and readily encourages ad-hoc cooperation (``can you please set everything-everyone on your subtree? we''ll handle it in unix.'''' / ``can you please set 777 on your subtree? or 770 group windows? we want to add windows silly-sid-permissions.''''). This is a big step better than existing systems with subtrees where Unix and Windows users are forced to cooperate. It would certainly work much better than the current system, where you look at your permissions and don''t have any idea whether you''ve got more, less, or exactly the same permission as what your software is telling you: the crappy autotranslation teaches users that all bets are off. It would be nice if, under my proposal, we could delete the unix tagspace entirely: chpacl ''(unix)'' chmod -R A- . but unfortunately, deletion of ACL''s is special-cased by Solaris''s chmod to ``rewrite ACL''s that match the UNIX permissions bits,'''' so it would probably have to stay special-cased in a tagspace system. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100930/038bbcc4/attachment.bin>
Nicolas Williams
2010-Sep-30 20:28 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Thu, Sep 30, 2010 at 02:55:26PM -0400, Miles Nordin wrote:> >>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes: > nw> Keep in mind that Windows lacks a mode_t. We need to interop > nw> with Windows. If a Windows user cannot completely change file > nw> perms because there''s a mode_t completely out of their > nw> reach... they''ll be frustrated. > > well...AIUI this already works very badly, so keep that in mind, too. > > In AFS this is handled by most files having 777, and we could do the > same if we had an AND-based system. This is both less frustrating and > more self-documenting than the current system. > > In an AND-based system, some unix users will be able to edit the > windows permissions with ''chmod A...''. In shops using older unixes > where users can only set mode bits, the rule becomes ``enforced > permissions are the lesser of what Unix people and Windows people > apply.'''' This rule is easy to understand, not frustrating, and > readily encourages ad-hoc cooperation (``can you please set > everything-everyone on your subtree? we''ll handle it in unix.'''' / > ``can you please set 777 on your subtree? or 770 group windows? we > want to add windows silly-sid-permissions.''''). This is a big step > better than existing systems with subtrees where Unix and Windows > users are forced to cooperate.Consider this chronologically-ordered sequence of events: 1) File is created via Windows, gets SMB/ZFS/NFSv4-style ACL, including inherittable ACEs. A mode computed from this ACL might be 664, say. 2) A Unix user does chmod(644) on that file, and one way or another this effectively reduces permissions otherwise granted by the ACL. 3) Another Windows user now fails to get write perm that they should have, so they complain, and then the owner tries to view/change the ACL from a Windows desktop. Now what? Can the user in (3) fix the permissions from Windows? For that to be possible the mode must implicitly get recomputed when the ACL is modified. What if (2) happens again? But, OK, this is a problem no matter what, whether we do groupmasking, discard, or keep mode separate from the ACL and AND the two. ZFS does, in fact, keep a separate mode, and it does recompute it when ACLs are modified. So this may just be a matter of doing the AND thing and not touching the ACL on chmod. Is that what you have in mind?> It would certainly work much better than the current system, where you > look at your permissions and don''t have any idea whether you''ve got > more, less, or exactly the same permission as what your software is > telling you: the crappy autotranslation teaches users that all bets > are off.No, currently you look at permissions that they reflect the ACL (with the group bits being the max of all non-owner@ and non-everyone@ ACEs).> It would be nice if, under my proposal, we could delete the unix > tagspace entirely: > > chpacl ''(unix)'' chmod -R A- .Huh?> but unfortunately, deletion of ACL''s is special-cased by Solaris''s > chmod to ``rewrite ACL''s that match the UNIX permissions bits,'''' so it > would probably have to stay special-cased in a tagspace system.Nico --
Nicolas Williams
2010-Sep-30 20:31 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Thu, Sep 30, 2010 at 03:28:14PM -0500, Nicolas Williams wrote:> Consider this chronologically-ordered sequence of events: > > 1) File is created via Windows, gets SMB/ZFS/NFSv4-style ACL, including > inherittable ACEs. A mode computed from this ACL might be 664, say. > > 2) A Unix user does chmod(644) on that file, and one way or another this > effectively reduces permissions otherwise granted by the ACL. > > 3) Another Windows user now fails to get write perm that they should > have, so they complain, and then the owner tries to view/change the > ACL from a Windows desktop. > > Now what? > > Can the user in (3) fix the permissions from Windows? For that to be > possible the mode must implicitly get recomputed when the ACL is > modified.Also, even if in (3) the user can fix the perms from Windows because we''d recompute the mode from the ACL, the user wouldn''t be able to see the "effective" ACL (as "reduced" by the mode_t that Windows can''t see). The only way to address that is... to do groupmasking. And that gets us back to the problems we had with groupmasking. Nico --
Miles Nordin
2010-Oct-01 00:14 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
>> Can the user in (3) fix the permissions from Windows?no, not under my proposal. but it sounds like currently people cannot ``fix'''' permissions through the quirky autotranslation anyway, certainly not to the point where neither unix nor windows users are confused: windows users are always confused, and unix users don''t get to see all the permissions. >> Now what? set the unix perms to 777 as a sign to the unix people to either (a) leave it alone, or (b) learn to use ''chmod A...''. This will actually work: it''s not a hand-waving hypothetical that just doesn''t play out. What I provide, which we don''t have now, is a way to make: /tub/dataset/a subtree -rwxrwxrwx in old unix [working, changeable permissions] in windows /tub/dataset/b subtree -rw-r--r-- in old unix [everything: everyone] in windows, but unix permissions still enforced this means: * unix writers and windows writers can cooperate even within a single dataset * an intuitive warning sign when non-native permissions are in effect, * fewer leaked-data surprises If you accept that the autotranslation between the two permissions regimes is total shit, which it is, then what I offer is the best oyu can hope for. My proposal also generalizes to other permissions autoconversion problems: * Future ACL translation stupidity that will happen as more bizarre ACL mechanisms are invented, or underspecified parts of current spec make different choices in different OS''s. - POSIX <-> NFSv4, Darwin <-> NFSv4 If Apple provides a Darwin <-> NFSv4 translation that''s silly, a match for Darwin NFS client IP''s in the share string could put these clients into a tagged ACL group. - AFP <-> NFSv4 ACL''s can be tagged by protocol for new weird protocols. If [new protocol]''s ACLs are a subset of NFSv4 ACL''s, then they can be implemented by the bridge and apply to users who don''t go through the bridge. The [new protocol] bridge will have an ACLspace all to itself, within which it can be certain nothing but itself will change ACL''s, so it can rely on never having to read NFSv4 ACL''s that do not match the subset it would feel inclined to write. Unix users will get an everything:everyone or 777 warning that someone else is managing the ACLspace. Yet, Unix users can descend into its private subtrees and muck around with ACL''s, and the Unix changes will still get enforced. It''s easy to search for all the changes made by Unix, vs all the changes made by [new protocol] bridge, and see if some are important. It''s easy to delete all of them at once if someone shouldn''t have been mucking arond from unix, or if the [new protocol] bridge was unleashed on a dataset that wasn''t dedicated to it and made a mess. This is a case where the [new protocol] bridge is using the ACL''s for two related but slightly-orthogonal purposes: to enforce security, and to store metadata. My proposal separates the two. - SMB <-> NFSv4, NFSv4 <-> NFSv4 I get that the NFSv4 ACL''s are supposed to match Windows perfectly, but if that turns out to be untrue, Linux and Windows clients could be put in separate ACL groups even though they''re both, in theory, using NFSv4 ACL''s. * zones running large software packages that have bizarre or misguided ACL behavior ACL''s are complicated enough that a lot of programmers will get them wrong. If you have a large, assertion-riddled app that will shit itself if it doesn''t see the ACL''s it expects, or autoset or autoremove ACL''s, or does other stupid things with ACL''s, you can put it into a zone and configure an ACL tag on the zone, segregating its ACL-writing from the rest of the system. Yet, its restrictions are still respected. If the app were setting ACL''s that don''t give enough permission, it wouldn''t work. but it may have hardcoded crap that stupidly opens up ACL''s, or refuses to work if ACL''s aren''t as open as it thinks they should be. Now you can fake it out whenever it calls getacl, but set other ACL''s kept secret from it and still return permission denied when you like. * (optional) a backup mechanism. If you make the choice ``global zone ignores ACLgroups with ''zoned'' bit set'''', then you can run backups in the global zone that won''t be stopped by ACL''s set by the inner zones, however you can still limit your backup process''s access by adding zoned=0 ACL''s. >> chpacl ''(unix)'' chmod -R A- . nw> Huh? I think you are confused because you didn''t read my proposal because it was too long, or the examples I wrote weren''t easy to understand. however if I try to repeat it in small pieces, I think it''ll just be even longer and harder to understand than the original. What''s more, if you don''t agree that the current autotranslation sucks, confuses people, and leaks unintended information, then the only way I could convince you to pay attention to me is with a talent for brevity that I just don''t have, so beyond this I think I''ll drop it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100930/909d058f/attachment-0001.bin>
Nicolas Williams
2010-Oct-01 00:41 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Thu, Sep 30, 2010 at 08:14:24PM -0400, Miles Nordin wrote:> >> Can the user in (3) fix the permissions from Windows? > > no, not under my proposal.Then your proposal is a non-starter. Support for multiple remote filesystem access protocols is key for ZFS and Solaris. The impedance mismatches between these various protocols means that we need to make some trade-offs. In this case I think the business (as well as the engineers involved) would assert that being a good SMB server is critical, and that being able to authoritatively edit file permissions via SMB clients is part of what it means to be a good SMB server. Now, you could argue that we should being aclmode back and let the user choose which trade-offs to make. And you might propose new values for aclmode or enhancements to the groupmask setting of aclmode.> but it sounds like currently people cannot ``fix'''' permissions through > the quirky autotranslation anyway, certainly not to the point where > neither unix nor windows users are confused: windows users are always > confused, and unix users don''t get to see all the permissions.Thus the current behavior is the same as the old aclmode=discard setting.> >> Now what? > > set the unix perms to 777 as a sign to the unix people to either (a) > leave it alone, or (b) learn to use ''chmod A...''. This will actually > work: it''s not a hand-waving hypothetical that just doesn''t play out.That''s not an option, not for a default behavior anyways. Nico --
Richard L. Hamilton
2010-Oct-03 04:55 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
> On Thu, Sep 30, 2010 at 08:14:24PM -0400, Miles > Nordin wrote: > > >> Can the user in (3) fix the permissions from > Windows? > > > > no, not under my proposal. > > Then your proposal is a non-starter. Support for > multiple remote > filesystem access protocols is key for ZFS and > Solaris. > > The impedance mismatches between these various > protocols means that we > need to make some trade-offs. In this case I think > the business (as > well as the engineers involved) would assert that > being a good SMB > server is critical, and that being able to > authoritatively edit file > permissions via SMB clients is part of what it means > to be a good SMB > server. > > Now, you could argue that we should being aclmode > back and let the user > choose which trade-offs to make. And you might > propose new values for > aclmode or enhancements to the groupmask setting of > aclmode. > > > but it sounds like currently people cannot ``fix'''' > permissions through > > the quirky autotranslation anyway, certainly not to > the point where > > neither unix nor windows users are confused: > windows users are always > > confused, and unix users don''t get to see all the > permissions. > > Thus the current behavior is the same as the old > aclmode=discard > setting. > > > >> Now what? > > > > set the unix perms to 777 as a sign to the unix > people to either (a) > > leave it alone, or (b) learn to use ''chmod A...''. > This will actually > work: it''s not a hand-waving hypothetical that just > doesn''t play out. > That''s not an option, not for a default behavior > anyways. > > NicoOne question: Casper, where are you? The guy that did fine-grained permissions IMO ought to have an idea of how to do something with ACLs that''s both safe and unsurprising for the various sorts of clients. -- This message posted from opensolaris.org
Nicolas Williams
2010-Oct-04 14:40 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Thu, Sep 30, 2010 at 08:14:24PM -0400, Miles Nordin wrote:> >> Can the user in (3) fix the permissions from Windows? > > no, not under my proposal.Let''s give it a whirld anyways:> but it sounds like currently people cannot ``fix'''' permissions through > the quirky autotranslation anyway, certainly not to the point where > neither unix nor windows users are confused: windows users are always > confused, and unix users don''t get to see all the permissions.No, that''s not right. Today you can fix permissions from any NFSv4 client that exports an NFSv4-style ACL interface to users. You can fix permissions from Windows. You can fix permissions a local Solaris shell. You can also fix permissions from NFSv3 clients (but you get POSIX Draft -> ZFS translated ACLs, which are confusing because they tend to result in DENY ACEs being scattered all over). You can also chmod, but you lose your ACL if you do that.> >> Now what? > > set the unix perms to 777 as a sign to the unix people to either (a) > leave it alone, or (b) learn to use ''chmod A...''. This will actually > work: it''s not a hand-waving hypothetical that just doesn''t play out.I would think that 777 would invite chmods. I think you are handwaving.> What I provide, which we don''t have now, is a way to make: > > /tub/dataset/a subtree > > -rwxrwxrwx in old unix > [working, changeable permissions] in windows > > /tub/dataset/b subtree > > -rw-r--r-- in old unix > [everything: everyone] in windows, but unix permissions > still enforced > > this means: > > * unix writers and windows writers can cooperate even within a single > dataset > > * an intuitive warning sign when non-native permissions are in effect, > > * fewer leaked-data surprisesI don''t understand what exactly you''re proposing. You''ve not said anything about how chmod is to be handled.> If you accept that the autotranslation between the two permissions > regimes is total shit, which it is, then what I offer is the best oyu > can hope for.If I could understand what you''re proposing I might agree, who knows. But I do think there''s other possibilities, some probably better than what you propose (whatever that is). Here''s a crazy alternative that might work (or not): allow users to pre-configure named ACLs where the names are {owner, group, mode}. E.g., we could have: .zfs/ACLs/<user>/[<group>:][d|-]<permissions>[.inherit] ^ ^^^ ^ | | | +-- owned by | | <user> +-- applies to | directory | or other | objects | | see below When chmod()ing an object... ZFS would search for the most specific matching file in .zfs/ACLs/ and, if found, would replace the chmod()ed object''s ACL with that of the .zfs/ACLs/... file found. The .inherit suffix would indicate that if the chmod() target''s parent directory has inherittable ACEs then they will be groupmasked and added to the ACEs from the .zfs/ACLs/... file to produce a final ACL. E.g., a chmod(0644) of /a/b/c/foo (say, a file owned by ''joe'' with group ''staff'', with /, /a, /a/b, and /a/b/c all being datasets), where c has inherittable ACEs would cause ZFS to search for .zfs/ACLs/joe/staff:-rw-r--r--.inherit, .zfs/ACLs/joe/-rw-r--r--.inherit, zfs/ACLs/joe/staff:-rw-r--r--, and .zfs/ACLs/joe/-rw-r--r--, first in /a/b/c, then /a/b, then /a, then /. I said this is "crazy". Is it? I think it probably is. This would almost certainly prove to be a hard-to-use design. Users would need to be educated in order to not be surprised... OTOH, it puts much more control in the hands of the user. These named ACLs could be inheritted from parent datasets as a way to avoid having to set them up too many times. And with the .inherit twist it probably has enough granularity of control to be useful (particularly if users are dataset-happy). Finally, these could even be managed remotely. I see zero chance of such a design being adopted. It''d be better, IMO, to go for non-POSIX-equivalent groupmasking and translations of POSIX mode_t and POSIX Draft ACLs to ZFS ACLs. For example: take the current translations, remove all owner@ and group DENY ACEs, then sort any remaining user DENY ACEs to be first, and any everyone@ DENY ACEs to be last. The results would surely be surprising to some users, but the kinds of mode_t and POSIX Draft ACLs where surprise is likely are rare. That''s two alternatives right there. Nico --
Miles Nordin
2010-Oct-04 18:28 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
>>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes:nw> I would think that 777 would invite chmods. I think you are nw> handwaving. it is how AFS worked. Since no file on a normal unix box besides /tmp ever had 777 it would send a SIGWTF to any AFS-unaware graybeards that stumbled onto the directory, alerting them that they needed to go learn something and come back. I understand that everything:everyone on windows doesn''t send SIGWTF, but 777 on unix for AFS sites it did. You realize it''s not hypothetical, right? AFS was actually implemented, widely, and there''s experience with it. If they failed to act on the SIGWTF, the overall system enforced the tighter of the unix permissions and the AFS ACL, so it fails closed. The current system fails open. Also AFS did no translation between unix permissions and AFS ACL''s so it was easy to undo such a mistake when it happened: double-check the AFS ACL is not too wide on the directories where you see unix people mucking around in case the muckers were responding to a real problem, then set the unix modes back to 777. nw> When chmod()ing an object... ZFS would search for the most nw> specific matching file in .zfs/ACLs/ and, if found, would nw> replace the chmod()ed object''s ACL with that of the nw> .zfs/ACLs/... file found. The .inherit suffix would indicate nw> that if the chmod() target''s parent directory has inherittable nw> ACEs then they will be groupmasked and added to the ACEs from nw> the .zfs/ACLs/... file to produce a final ACL. This proposal, like the current situation, seems to make chmod configurable to act like ``not chmod'''' which IMHO is exactly what''s unpopular about the current regime. You''ve tried to leave chmod active on windows trees and guess at the intent of whoever invokes chmod, providing no warning that you''re secretly doing ``approximately'''' what he asked for rather than exactly. Maybe that flies on Windows, but on Unix people expect more precision: thorough abstractions that survive corner cases and have good exception handling. The problem is not that Unix people refuse to learn about Windows permissions to accomodate windows, or that they are too stupid to understand the ''chmod A...'' stuff in the manpage. They will learn if you ask them to learn. The problem is that you don''t ask them. The repeated complaint is that when OTHER USERS hamfist a bunch of stuff with chmod: (1) they destroy the correct ACLs that were put on those files by people who do know wtf is going on. The ACL''s are hard to get right, and there''s no simple way for the people who understand ACL''s to undo the damage caused by blind chmod''ing (2) it''s insecure because it doesn''t reliably implement the will of the unaware person invoking chmod and gives that person no warning. AFS had neither problem, nor my proposal. NFSv4 as-built has both. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101004/8f3f17a1/attachment.bin>
Nicolas Williams
2010-Oct-05 21:55 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Mon, Oct 04, 2010 at 02:28:18PM -0400, Miles Nordin wrote:> >>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes: > > nw> I would think that 777 would invite chmods. I think you are > nw> handwaving. > > it is how AFS worked. Since no file on a normal unix box besides /tmpBut would the AFS experience translate into double plus happiness for us?> ever had 777 it would send a SIGWTF to any AFS-unaware graybeards that > stumbled onto the directory, alerting them that they needed to go > learn something and come back.A signal?! How would that work when the entity doing a chmod is on a remote NFS client?> I understand that everything:everyone on windows doesn''t send SIGWTF, > but 777 on unix for AFS sites it did. You realize it''s not > hypothetical, right? AFS was actually implemented, widely, and > there''s experience with it.Yes... but I''m skeptical about the universality of that experience''s applicability. Specifically: I don''t think it could work for us. AFS developers had fewer constraints than Solaris developers. It is no surprise that they were able to find happy solutions to these sorts of problems long ago. OpenAFS has a Windows native client and an Explorer shell extension (which surely handles chmod?). However, we don''t have the luxury of telling customers to install third-party (possibly ours, whatever) Windows native clients for protocols other than SMB, nor can we tell them to install Explorer shell extensions. Solaris'' SMB server needs to work out of the box and without the limitations implied by having a separate ACL and mode (well, we have that now, but we always compute a new mode from the new ACL when ACLs are changed).> If they failed to act on the SIGWTF, the overall system enforced the > tighter of the unix permissions and the AFS ACL, so it fails closed. > The current system fails open.The current system fails closed (by discarding the ACL and replacing it with a new one based entirely on the new mode).> Also AFS did no translation between unix permissions and AFS ACL''s so > it was easy to undo such a mistake when it happened: double-check the > AFS ACL is not too wide on the directories where you see unix people > mucking around in case the muckers were responding to a real problem, > then set the unix modes back to 777.Right, but with SMB in the picture we don''t have this luxury. You seem unwilling to accept that one constraint.> nw> When chmod()ing an object... ZFS would search for the most > nw> specific matching file in .zfs/ACLs/ and, if found, would > nw> replace the chmod()ed object''s ACL with that of the > nw> .zfs/ACLs/... file found. The .inherit suffix would indicate > nw> that if the chmod() target''s parent directory has inherittable > nw> ACEs then they will be groupmasked and added to the ACEs from > nw> the .zfs/ACLs/... file to produce a final ACL. > > This proposal, like the current situation, seems to make chmod > configurable to act like ``not chmod'''' which IMHO is exactly what''s > unpopular about the current regime. You''ve tried to leave chmodTo some degree, yes. It''s different though, and might conceivably be acceptable, though I don''t think it will be (I was illustrating potential alternatives). But I really like one thing about it: most apps shouldn''t care about ACL contents, they should care about context-specific permissions changes. In a directory containing shared documents the intention should typically be "share with all these people", while in home directories the intention should typically be "don''t share with anyone" (but this will vary; e.g., ~/.ssh/authorized_keys needs to be reachable and readable by everyone). Add in executable versus not- executable, and you have a pretty complete picture -- just a few "named" ACLs at most, per-dataset. If we could replace chmod(2) with a version that takes actual names for pre-configured ACLs, _that_ would be great. But we can''t for the same reason that we can''t remove chmod(2): it''s a widely used interface.> active on windows trees and guess at the intent of whoever invokes > chmod, providing no warning that you''re secretly doing > ``approximately'''' what he asked for rather than exactly. Maybe that > flies on Windows, but on Unix people expect more precision: thorough > abstractions that survive corner cases and have good exception > handling.Look, mode is a pretty lame hammer -- ACLs are far, far more granular-- but it''s a hammer that many apps use. Given the lack of granularity of modes, I think an approximation of intent is the best we can do. Consider: both, aclmode=discard and aclmode=groupmask behaviors can be considered to be what the user intended. How do you know if the user intended for other users and groups to retain access limited to the group bits of a new mode? You can''t, not without asking the user. So aclmode=discard is certainly an approximation of user intent, and so aclmode=groupmask must be considered an approximation as well. That would be the best argument for adding aclmode back in: given our unwillingness to maintain separate ACL and mode, whatever we do with chmods, it can only be an approximation, so who are we to say which approximation is best? And the best counter-argument is that "best approximation" will vary so widely, even for any one customer, that a dataset property will be insufficiently granular, so there''s not much we can do.> The problem is not that Unix people refuse to learn about Windows > permissions to accomodate windows, or that they are too stupid to > understand the ''chmod A...'' stuff in the manpage. They will learn ifThe problem is legacy, as well as a lack of easy-to-use APIs for manipulating ACLs.> you ask them to learn. The problem is that you don''t ask them. TheMaybe so.> repeated complaint is that when OTHER USERS hamfist a bunch of stuff > with chmod: > > (1) they destroy the correct ACLs that were put on those files by > people who do know wtf is going on. > > The ACL''s are hard to get right, and there''s no simple way for > the people who understand ACL''s to undo the damage caused by > blind chmod''ing > > (2) it''s insecure because it doesn''t reliably implement the will of > the unaware person invoking chmod and gives that person no > warning.No, you''re wrong about (2). The "failure" is safe. It just might not be what the user wanted (i.e., more users will lose access than the user had intended). A good workaround is to write a tool to fix ACLs periodically.> AFS had neither problem, nor my proposal. NFSv4 as-built has both.You seem to be in denial. You continue to ignore the constraint that Windows clients must be able to fully control permissions in spite of their inability to perceive and modify file modes. Or perhaps you wish we''d drop that constraint. Or perhaps you wish we''d give you the option to. But we''d rather have one very good option than N dataset-level options that mostly serve to confuse users (although keep in mind that I''m not in the ZFS team, much less do I speak for them). Nico --
Miles Nordin
2010-Oct-06 20:38 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
>>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes:nw> The current system fails closed wrong. $ touch t0 $ chmod 444 t0 $ chmod A0+user:$(id -nu):write_data:allow t0 $ ls -l t0 -r--r--r--+ 1 carton carton 0 Oct 6 20:22 t0 now go to an NFSv3 client: $ ls -l t0 -r--r--r-- 1 carton 405 0 2010-10-06 16:26 t0 $ echo lala > t0 $ wide open. NFSv3 and SMB sharing the same dataset is a use-case you claim to accomodate. This case fails open once Windows users start adding ''allow'' ACL''s. It''s not a corner case; it''s a design that fails open. >> ever had 777 it would send a SIGWTF to any AFS-unaware >> graybeards nw> A signal?! How would that work when the entity doing a chmod nw> is on a remote NFS client? please find SIGWTF under ''kill -l'' and you might understand what I meant. nw> You seem to be in denial. You continue to ignore the nw> constraint that Windows clients must be able to fully control nw> permissions in spite of their inability to perceive and modify nw> file modes. You remain unshakably certain that this is true of my proposal in spite of the fact that you''ve said clearly that you don''t understand my proposal. That''s bad science. It may be my fault that you don''t understand it: maybe I need to write something shorter but just as expressive to fit within mailing list attention spans, or maybe my examples are unclear. However that doesn''t mean that I''m in denial nor make you right---that just makes me annoying. -- READ CAREFULLY. By reading this fortune, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101006/538dad33/attachment.bin>
Nicolas Williams
2010-Oct-06 20:51 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Wed, Oct 06, 2010 at 04:38:02PM -0400, Miles Nordin wrote:> >>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes: > > nw> The current system fails closed > > wrong. > > $ touch t0 > $ chmod 444 t0 > $ chmod A0+user:$(id -nu):write_data:allow t0 > $ ls -l t0 > -r--r--r--+ 1 carton carton 0 Oct 6 20:22 t0 > > now go to an NFSv3 client: > $ ls -l t0 > -r--r--r-- 1 carton 405 0 2010-10-06 16:26 t0 > $ echo lala > t0 > $ > > wide open.The system does what the ACL says. The mode fails to accurately represent the actual access because... the mode can''t. Now, we could have chosen (and still could choose to) represent the presence of ACEs for subjects other than owner@/group@/everyone@ by using the group bits of the mode to represent the maximal set of permissions granted. But I don''t consider the above "failing open".> nw> You seem to be in denial. You continue to ignore the > nw> constraint that Windows clients must be able to fully control > nw> permissions in spite of their inability to perceive and modify > nw> file modes. > > You remain unshakably certain that this is true of my proposal in > spite of the fact that you''ve said clearly that you don''t understand > my proposal. That''s bad science.*You* stated that your proposal wouldn''t allow Windows users full control over file permissions.> It may be my fault that you don''t understand it: maybe I need to write > something shorter but just as expressive to fit within mailing list > attention spans, or maybe my examples are unclear. However that > doesn''t mean that I''m in denial nor make you right---that just makes > me annoying.Yes, that may be. I encourage you to find a clearer way to express your proposal. Nico --
Miles Nordin
2010-Oct-06 21:19 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
>>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes:nw> *You* stated that your proposal wouldn''t allow Windows users nw> full control over file permissions. me: I have a proposal you: op! OP op, wait! DOES YOUR PROPOSAL blah blah WINDOWS blah blah COMPLETELY AND EXACTLY LIKE THE CURRENT ONE. me: no, but what it does is... you: well then I don''t even have to read it. It''s unacceptable because $BLEH. me: untrue. My proposal handles $BLEH just fine. you: you just said it didn''t! me: well, it does. Please read it. you: I read it and I don''t understand it. Anyway it doesn''t handle $BLEH so it''s no good. This is not really working, and concision is the problem. so, I now, today, state: My proposal allows Windows users full control over file permissions. nw> Yes, that may be. I encourage you to find a clearer way to nw> express your proposal. So far, it''s just us talking. I think I''ll wait and see if anyone besides you reads it. If so, maybe they can ask questions that help me clarify it. If no one does, it''s probably not interesting here anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101006/c36ef352/attachment.bin>
Nicolas Williams
2010-Oct-06 21:34 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Wed, Oct 06, 2010 at 05:19:25PM -0400, Miles Nordin wrote:> >>>>> "nw" == Nicolas Williams <Nicolas.Williams at oracle.com> writes: > > nw> *You* stated that your proposal wouldn''t allow Windows users > nw> full control over file permissions. > > me: I have a proposal > > you: op! OP op, wait! DOES YOUR PROPOSAL blah blah WINDOWS blah blah > COMPLETELY AND EXACTLY LIKE THE CURRENT ONE. > > me: no, but what it does is...The correct quote is: "no, not under my proposal." That''s from a post from you on September 30, 2010, with Message-Id: <oqd3ruvkf3.fsf at castrovalva.Ivy.NET>. That was a direct answer to a direct question. Now, maybe you wish to change your view. That''d be fine. Do not, however, imply that I''m liar though, not if you want to be taken seriously. Please re-write your proposal _clearly_ and refrain from personal attacks. Cheers, Nico --
Richard Elling
2010-Oct-10 04:52 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
Are we living in the past? In the bad old days, UNIX systems spoke NFS and Windows systems spoke CIFS. The cost of creating a file system was expensive -- slices, partitions, etc. With ZFS, file systems (datasets) are relatively inexpensive. So, are we putting too many constraints into a system (ZFS) which is busy trying to remove constraints? Is it reasonable to expect that ZPL is the only kind of "file system" ZFS customers need? Is it high time for a ZCIFS dataset? -- richard
Nicolas Williams
2010-Oct-11 04:08 UTC
[zfs-discuss] tagged ACL groups: let''s just keep digging until we come out the other side
On Sat, Oct 09, 2010 at 09:52:51PM -0700, Richard Elling wrote:> Are we living in the past? > > In the bad old days, UNIX systems spoke NFS and Windows systems spoke > CIFS. The cost of creating a file system was expensive -- slices, > partitions, etc. > > With ZFS, file systems (datasets) are relatively inexpensive. > > So, are we putting too many constraints into a system (ZFS) which is > busy trying to remove constraints? Is it reasonable to expect that > ZPL is the only kind of "file system" ZFS customers need? Is it high > time for a ZCIFS dataset?I don''t quite understand what you mean. ZPL is just a POSIX layer. It _happens_ to be used not just by the system call layer in Solaris, but also by the SMB and NFS servers, but you could also imagine the SMB and NFS servers using the DMU directly while maintaining on-disk compatibility with the ZPL. Not using the ZPL does not necessitate having a different on-disk format, or different semantics. Now, if you were asking about dataset properties that make a dataset behave more like what Windows expects or more like what Unix expects, that''s different, but that wouldn''t require junking the ZPL. Nico --