I have always hated and despised ACLs.  While they give, obviously, more
precise control over access, in practice I find that I never need the
extras they give, and meanwhile I frequently find them preventing me doing
simple ordinary things.  And they are tremendously obfuscatory; I can
never figure out WHY I can't do some simple normal thing.

So, I've somehow got this directory (or sub-tree) protected wrong, I'm
sure.  In fact, it's pretty clear that ACL#1 is at least part of the
problem (no idea how it got there; this fileserver has been in service
since 2006, and this particular directory has been not used for several 
years).

bash-4.0$ pfexec ls -ldv laptop-backup/
drwx---r-x+  3 ddb      other          9 Nov 28 22:48 laptop-backup/
     0:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/execute:deny
     1:owner@::deny
     2:user:ddb:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/delete/read_acl/write_acl
         /write_owner/synchronize:allow
     3:group:other:list_directory/read_data/read_xattr/execute
         /read_attributes/read_acl/synchronize:allow
     4:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     5:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     6:group@::allow
     7:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/delete/read_acl/write_acl
         /write_owner/synchronize:file_inherit/dir_inherit/inherit_only
         /inherited:allow
     8:owner@:read_xattr/write_xattr/delete_child/read_attributes
         /write_attributes/delete/read_acl/synchronize:inherited:allow

This is supposed to be a space I rsync my laptop filesystem into.  I run
as user ddb.  What I want is for user ddb to be able to read and write
this subtree, and nobody else.  What's the simple way of getting there?  I
can delete everything there.

"rm -rf laptop-backup; mkdir laptop-backup; chmod 700 laptop-backup"
doesn't work, I end up with the user:ddb::deny ACL again.  Why are there
any ACLs at all given what I did?  I guess I'm inheriting things from
higher up -- but my other directories I can access.
-- 
David Dyer-Bennet, [email protected]; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

_______________________________________________
opensolaris-help mailing list
[email protected]

Reply via email to