POSIX Default ACLs, umask and Project Directories

I’ve recently come across a situation where the inherent design of POSIX ACLs has left me scratching my head for a solution to the problem of setting up a “project” or “group share” directory on Linux. The problem is as follows: We have several different projects or groups that desire a directory where any and every file created, copied or moved to said directory will become owned by a particular group and have group read/write permissions set automatically.

Most of the problem is solved through age-old UNIX techniques. For group ownership, all we need to do is setup the top-level directory to be owned by the “project” or “group share” group and setgid the directory:

$ mkdir project1
$ chown .projgroup project1
$ chmod g+s project1

This effectively forces every file created, moved or copied into the “project1” directory to be owned by group “projgroup”. So far, so good. The difficulties begin when we attempt to use default ACLs to enforce the permissions of any files created, moved or copied into the directory.

The POSIX ACL standard defines “default” ACLs which can be applied to a directory, which are in turn inherited by newly created/copied/moved child files and directories. While the default ACLs are inherited properly, the ACL mask when applied to files copied into the group share directory WITHOUT previous group write set prevents the files from being group writable!

$ getfacl project1
# file: project1
# owner: root
# group: projgroup

So far so good, right?

$ ls -alh test
-rw-r--r--  1 user1 user 0 Apr 23 15:10 test
$ cp test project1
$ ls -alh project1/test
-rw-r--r--+ 1 user1 projgroup 0 Apr 23 15:10 project1/test

What the… ?!?! No group write? Noooooo!

$ getfacl project1
# file: project1/test
# owner: user1
# group: projgroup
group::rw-			#effective:r--
group:projgroup:rw-		#effective:r--

And so we have the great POSIX ACL mask problem, which is by design in fact. Still looking for a complete solution that doesn’t involve global trying to force a specific umask on every account… It would be nice if I could ensure that every file had group write set before it was copied into the group share directory but alas, I cannot. Telling users to manually check and change permissions is also a pain. Cron jobs to change group write recursively is also ugly. Please, someone provide me with the solution.

4 thoughts on “POSIX Default ACLs, umask and Project Directories

  1. Hi,

    I too am frustrated by this behavior as I am also considering POSIX ACLs for this purpose. However, it turns out this is not a failure of ACLs.

    This is a “failure” of cp. cp preserves mode, ownership, and timestamps by default. Thus, it seems there is no way to achieve what we want without some sort of user intervention, be it calling chmod/setfacl after cp or using the –no-preserve=mode option.

    Personally, I am considering the cron job approach as this is the simplest way to do it, although this would incur some amount of latency since the task is periodic and not in response to file creation. Another approach would be to write a small daemon that uses something like dnotify to automatically enforce permissions on new files, but I’m feeling quite lazy…

    PS: Bear in mind, that cp did not actually respect –no-preserve=mode until this year: http://savannah.gnu.org/bugs/?27146

    1. If you’re going to go with the separate job idea, instead of a periodic cron job, use inotify wait to set a watch on the directory and change the permissions when it gets tripped by a file creation notification. Should be practically zero latency, and at the same time won’t churn the filesystem with the check when nothing’s been changed (Or at all necessarily, you can have it return the path to the newly created file.)

  2. i just discovered the same problem myself. no solution yet, but will continue to search.

    one potential solution i am pondering is to set the default acl to group write for user home directories too. that should cover most cases of new files being created. not too pretty, but better than a default umask.

Leave a Reply

Your email address will not be published. Required fields are marked *