Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 various Just 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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs proerty aclmode gone in 147?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
