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
