On Fri, 26 Feb 2010, Nicolas Williams wrote: > a) clobber the ACL; > b) map the change as best you can to an ACL change; > c) ignore the rwx bits in the mode mask (except on create from a POSIX > open(2)/creat(2), in which case the ACL has to be derived from the > initial mode); > d) fail the chmod().
Option d I believe maps to my proposed aclmode=deny; option c I *think* lines up with my aclmode=discard, and even takes care of the issue of flipping the suid/sgid et al bits, as an absolute chmod of 0200 would turn on sgid and the ugo parts would be ignored (and the ACL would only need to be derived if the three special ACE's aren't specified by inheritance (which they probably would be if somebody configured option c)). a and b are both currently available, what do I need to do to get you on board with implementing c and d ;)? > All three can be surprising! Agreed. There is no one, two, three, or even four different ways of handling this issue that will meet the needs of every possible deployment. But without getting into ridiculous levels of complexity, having some reasonable number of options available seems highly desirable. Evil thought -- implement a way to attach a custom chmod->ACL mapper to a zfs filesystem allowing some basic scripting language to specify what happens. Then everybody could make it do exactly what they want :). -- 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
