Re: backwards ACL behavior

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: backwards ACL behavior

Jason Van Pelt
I may have stated parts of this in previous messages, but here's where things appear to stand right now:

Using posix permissions 1777 (wrxwrxwrt with the sticky bit set) only functions in the intended way (everyone can read/create, only owner can edit/delete) for immediate children of the folder with that permission if ACLs are enabled.  The sticky bit is not inherited by newly-created folders in this case.  New folders get the posix permission 777, so anyone can edit/delete files created in these subfolders.

Trying to do it with ACLs fails, it appears, because ACEs don't apply to built in groups like everyone or owner, at least in the tests I've performed.

The following example shows permissions that are meant to set a folder where anyone can read,add files, and add subdirectories, but only edit/delete their own files and subdirectories.  The result instead is that everyone can list and read files, but no one can add, edit, or delete files.

drwxrwxr-x + 2 root  admin  68 Mar  5 13:26 Public
 0: group:everyone allow list,add_file,search,add_subdirectory,readattr,readextattr,readsecurity,file_inherit,directory_inherit
 1: group:owner allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

Users can't even edit/delete the files they own.  The following file, added and chowned by root, cannot be edited or deleted by the user, hsts.

-rwx------ + 1 hsts  admin  13 Mar  5 14:22 test
 0: group:everyone inherited allow read,write,execute,append,readattr,readextattr,readsecurity
 1: group:owner inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown

The only way I can find to allow someone to edit/delete a file is if they have POSIX write or ACL delete_child permission applied to the parent folder for that user or a non-built-in group the user is a member of.  This allows users to delete any child file or folder.  If anyone knows any secrets, I'd love to hear them.

Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list      ([hidden email])
Help/Unsubscribe/Update your Subscription:

This email sent to [hidden email]