I was having a conversation a few weeks ago about the various possible ways
of handling a chmod() on a file/directory with an acl. I suggested that one
option be for it just be ignored, as the file presumably had that acl for a
reason and the creator probably doesn't want it indiscriminitely whacked.
The feedback was that the internal Sun POSIX compliance police wouldn't
like that ;).
But you know, every day I run across yet another annoying legacy script or
application or client that has no idea what an acl is and screws up my
carefully crafted permissions. I'm finding it virtually impossible to
maintain any level of sanity, and short of sweeping through all my files on
a regular basis and checking/fixing acl's, it seems there's no way to
realisticly maintain them.
So why not a option to either ignore or fail any attempts to chmod() a
file/directory with a non-trivial acl? Obviously this wouldn't be the
default, and likely unwise for a root pool ;), but if someone wants an acl
pure dataset why not give it to them? The ability to be POSIX compliant is
clearly required, and to be that way by default is perhaps best, but on the
other hand providing the user features that they need should rank pretty
high on the importance scale too.
So I'd propose two additional aclmode options:
* ignore -- any chmod() attempt on a file/directory with a non-trivial acl
is silently ignored and returns success
* deny -- any chmod() attempt on a file/directory with a non-trivial acl
fails with EPERM.
You can already achieve acl-pure datasets under opensolaris if you only
access them via cifs; why should nfs or local shell access not be able to
have the same functionality?
--
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
