Cannot save over an ACL file unless the "Delete" permission is granted

How can I enable a group to create and append files and folders but not allow [delete]?

Assuming that you have set the ACL entry or entries correctly (see my ACL Tips post for how to do that - http://discussions.apple.com/thread.jspa?threadID=318161), the short answer is that presently it is not possible to have all applications respect other write-type controls when controls that allow deletion are omitted (or denied). (The delete control allows the object carrying or inheriting the control to be deleted. The delete_child control allows the contents of the object carrying or inheriting the control to be deleted. Since deletion of an object is granted by either one or the other, denying deletion of the object requires denying both - DeMorgan's Law. To keep the logic as simple as possible, I'm going to refer to denying the ability to delete as not having delete-type controls from here on.)

The problem is not that you're setting the ACL entry or entries incorrectly; rather, it is how applications have become accustomed to saving. The problem is not specific to Mac OS X Server - you can replicate the problem by creating a disk image, enabling ACLs on it, and testing it on the client.

Here are the highlights:

1. With the ACL entry (or entries) set such that all write-type controls are allowed except delete-type controls are not, you can create a new folder in the object using Terminal (e.g. mkdir /path to/newfolder). However, the Finder will not allow the New Folder command to be executed and will display the "marked out pen" logo in the window of the object, indicating that the object is read-only.

This would suggest that the Finder checks for the ability to delete before it decides if a folder is read/write, likely because it has the habit of creating folders with the name "untitled folder" then allowing renaming of that folder. This behavior would have to be changed. However that still doesn't explain why you cannot copy a folder to the folder where delete-type controls are omitted or denied.

2. This is actually a larger problem: Try opening a new document in TextEdit, enter a line of text, then attempt to Save that file to the folder where delete-type controls are omitted or denied. The initial Save might be successful. Now add a second line of text and attempt to Save that. At this point, if you haven't already, you should receive a "could not save" error. But there's more: Inspecting the directory listing of the affected folder via ls -al will show that there is a temporary file whose name begins with a dot (.) created by TextEdit. Viewing that file with pico /path to/tempfile reveals that TextEdit did actually write the added text to the temporary file, but the Save process couldn't complete for some other reason.

And this is what I think happens: When TextEdit has the path for saving a file (e.g. /path/somefile.rtf), and you make a modification and then Save, the process works as follows: your modifications are written to a temporary file, the original file is closed and deleted, then the temporary file is renamed with the name of the original file. Since TextEdit saves its temporary file in the same path as the original, saving fails on the second step.

What's worse is that TextEdit represents the majority of application behavior when it comes to saving. InDesign, for example, goes a step further, creating a corresponding "lock file " (filename.idlk corresponding to filename.indd), which it doesn't even attempt to hide, whenever you simply open the filename.indd document. Upon closing, the idlk file is deleted, so even if saving were successful after initially opening filename.indd, the next time you opened filename.indd, you'd get an error because InDesign would have expected to not found the filename.idlk file there.

I have filed a bug report with Apple on this for the Finder's behavior. Apple lists the bug with Problem ID 4563892, and it's still open. Here is the text of the report:

___
TITLE: Finder - Does not grant write access when ACLs apply unless Delete is allowed

26-May-2006 01:04 AM Gerrit DeWitt:
Summary

When an ACL entry providing one or more write commands other than delete or delete_child is set for a given folder, and an applicable user, whose POSIX access provides, at maximum, read & execute (read only), accesses it via Finder, all write commands are ignored unless the either delete or delete_child entry is present (or otherwise inherited).

Steps to Reproduce
(These steps demonstrate this bug using a disk image with ACLs enabled. This is not the only way to cause the problem; please see Regression.)

1. Use Disk Utility to generate a new disk image using a Mac OS Extended (Journaled) or Mac OS Extended filesystem. Mount that disk image and ensure that the "ignore permissions" box is NOT checked. (In other words, ensure that permissions apply to the mounted volume.) For this example, suppose "test_volume" is the mounted disk image appearing at /Volumes/test_volume.
2. Using fsaclctl or Workgroup Manager, enable ACLs on the volume: sudo fsaclctl -e -p /Volumes/test_volume. Unmount and remount the volume to ensure that the Effective Permissions model is in effect for it.
3. Let testing_user be a standard user or an administrator with his/her primary group set to staff (GID 20). As root, create a new directory, test_directory, in /Volumes/test_volume and set permissions such that: 1. The testing_user is not the owner of test_directory; 2. The POSIX permissions return, at most, read and execute for testing_user; and 3. Create an ACL entry that allows testing_user to perform all ACL commands associated with Read & Write, except the delete and delete_child commands.

In pseudocode:

sudo mkdir /Volumes/test volume/testdirectory
sudo chown root:admin /Volumes/test volume/testdirectory
sudo chmod 755 /Volumes/test volume/testdirectory
sudo chmod +a "testing_user allow readattr,readextattr,readsecurity,read,execute,list,search,writeattr,writeextat tr,add subdirectory,add_file,write,append,file_inherit,directoryinherit" /Volumes/test volume/testdirectory

4. Log in as testing_user and mount the test_volume. Perform the following tests:

A. Using Terminal, attempt to create a new folder and file inside of /Volumes/test volume/testdirectory: mkdir /Volumes/test volume/test_directory/seconddirectory and touch /Volumes/test volume/test_directory/testfile

B. Using Finder, attempt to create a new folder inside of /Volumes/test volume/testdirectory via New Folder, New Smart Folder, or New Burn Folder.

C. Using Terminal, attempt to copy a folder and a file from one location to /Volumes/test volume/testdirectory using mv, ditto, or cp.

D. Using Finder, attempt to copy a folder and a file from one location to /Volumes/test volume/testdirectory.

E. Using Terminal, perform a directory listing using ls -el /Volumes/test volume/testdirectory, and note the permissions listed.

F. Using Finder, inspect the Get Info window for /Volumes/test volume/testdirectory, and note the permissions listed.

Expected Results
for tests A, B, C, D, E, and F previously mentioned

A. Creating a new folder should be successful. Creating a new file should be successful.
B. Creating a new folder should be successful.
C. Copying folders and files via mv, ditto, and cp should be successful.
D. Copying folders and files via Finder should be successful.
E. The directory listing should show POSIX permissions of root:admin 755, and the ACL entry for testing_user allowing readattr,readextattr,readsecurity,list,search,writeattr,writeextattr,add_subdir ectory, and add_file.
F. The Info window should show one entry in the Details list of the Ownership & Permissions section for testing_user. It should list the following: Read attributes, Write attributes, Read extended attributes, Write extended attributes, Read permissions, List entries, Find files, Add files, and Add folders. It should also show "You can read and write but not delete" or something to that effect.

Actual Results
for tests A, B, C, D, E, and F mentioned in the Steps to Reproduce section

A. same as expected results
B. The Finder does not allow the creation of any new folders.
C. same as expected results
D. The Finder does not allow folders or files to be copied to the test directory.
E. same as expected results
F. Same as expected with the exception that the caption above the Details list in the Ownership & Permissions section of the Get Info window reads, "You can only read."

Regression

* This problem occurs on any PowerPC computer using Mac OS X 10.4.6 or earlier. No testing has been done with the Intel build of Mac OS X 10.4.6, although I suspect that the results should be the same. Installation of Security Update 2006-003 does not alter the results.

* Problem is reproducible 100% of the time unless POSIX permissions grant write permission for the affected user (testing_user in this example). That's expected given how Effective Permissions are calculated using (POSIX level returned) union (applicable ACL allow entries) take away (applicable ACL deny entries).

* Problem is not limited to local HFS+ volumes where ACLs are enabled. This problem can also be seen when accessing an AFP share point that resides on a volume with ACLs enabled, hosted by Mac OS X Server 10.4.6.

Notes

I do realize that delete and delete_child are necessary for some applications to be able to save data, as they don't write data back to the same file (via append). With TextEdit, for example, delete commands would be necessary for Save/Save As to work as TextEdit creates a temporary file while saving. However, the Finder should be able to at least create new folders and copy files or folders to parent directories where add_subdirectory and add_file are enabled.

--Gerrit DeWitt
Apple Certified System Administrator

I should also mention this, because somebody else will bring it up. 🙂

I edited your original question in my last post from this:

How can I enable a group to create and append files and folders but not allow them to throw another owners file away?

to this:

How can I enable a group to create and append files and folders but not allow [delete]?

For a couple of reasons. First off, the POSIX owner is not part of ACL entries, even though POSIX permissions and ACL permissions are used to calculate the Effective Permissions. Your question quite clearly was related to ACLs, so it simplifies your request.

Secondly, there technically is a way to do what your first question requests - have a folder that allows users (or a group of users) to create new files but only allow deletion by the original owner. I don't think this is what you were asking, but knowing this may help:

The answer involves setting a special POSIX permission bit, called the "sticky bit," which only allows deletion by the file's owner. This can be used with ACLs, so long as you're not denying delete via applicable ACL entry.

There is one caveat to this, though: the POSIX owner must be a user, and not a group, so even if the group "designers" had read and write access to a folder whose sticky bit was set, any new files created by a member of that group (say, user "sally") could only be deleted by that user (only "sally", not "tim" anyone else who is a member of "designers").

For more on permissions assigned to newly-created files and folders, please see my answer to this post: http://discussions.apple.com/thread.jspa?threadID=548014

To set the sticky bit for a folder, use chmod: chmod 1755 /path to folder/ sets the sticky bit for the chosen path with owner, group, and everyone permissions set to 755. POSIX special permission bits are prepended to owner, group, and everyone else bits.

You could use the sticky bit in conjunction with the set-UID bit to define ensure that the owners of newly-created files were set to the owner of the parent folder (this is different from the "inherit POSIX permissions from parent" AFP option), but I don't think that level of complexity would produce desired results, even if used.

--Gerrit