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
