Setfacl incorrectly changes group permissions

Issue #1: Rsync is dropping ACLs

After applying the ACL permissions you need to take care that when you perform your rsync that you're using either the -A or --acls switch. This instructs rsync to make sure to preserve these when doing the sync.

excerpt from rsync man page

    -A, --acls                  preserve ACLs (implies -p)

Issue #2: No ACL permissions

In looking at your example it does contain permissions as follows.

traditional perms

# owner: stian
# group: admin
user::rwx
group::r-x
other::r-x

ACLs

default:user::rwx
default:user:www-data:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

But these ACLs are for the creation of new objects, and don't work exactly the way you think. You need to still create an entry for user www-data in addition to the default ACL perms.

Example

$ pwd
/tmp/somedir

$ mkdir data
$ setfacl -R -d -m u:gopher:7 data

$ getfacl data
# file: data
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:gopher:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

An experiment

Now let's try and write a file to the data directory as user gopher.

$ sudo -u gopher touch /tmp/somedir/data/afile
touch: cannot touch `/tmp/somedir/data/afile': Permission denied

Look familiar?

Adding additional ACL permissions

It's because you need to add a ACL for the user www-data, the default rules aren't for access, they're for creating new files/directories.

$ setfacl -R -m u:gopher:7 data

Now check the data directory again:

$ getfacl data
# file: data
# owner: root
# group: root
user::rwx
user:gopher:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:gopher:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

The only difference we now have a ACL saying that user gopher has rwx access:

user:gopher:rwx

Repeat the experiment

Try writing a data to the directory again:

$ sudo -u gopher touch /tmp/somedir/data/afile
$

It worked!!! Double check the resulting file:

$ ls -l /tmp/somedir/data/afile
-rw-rw-r--+ 1 gopher gopher 0 Oct  7 21:36 /tmp/somedir/data/afile

Permissions are generally not propagated by the directory that files are being copied into, rather new permissions are controlled by the user's umask. However when you copy a file from one location to another it's a bit of a special case where the user's umask is essentially ignored and the existing permissions on the file are preserved. Understanding this concept is the key to getting what you want.

So to copy a file but "drop" its current permissions you can tell cp to "not preserve" using the --no-preserve=all switch.

Example

Say I have the following file like you.

$ mkdir -m 744 somedir

$ touch afile
$ chmod 400 afile 

$ ll
total 0
-r--------. 1 saml saml 0 Feb 14 15:20 afile

And as you've confirmed if we just blindly copy it using cp we get this:

$ cp afile somedir/
$ ls -l somedir/
total 0
-r--------. 1 saml saml 0 Feb 14 15:20 afile

Now let's repeat this but this time tell cp to "drop permissions":

$ rm -f somedir/afile 

$ cp --no-preserve=all afile somedir/

$ ls -l somedir/
total 0
-rw-rw-r--. 1 saml saml 0 Feb 14 15:21 afile

So the copied file now has its permissions set to 664, where did it get those?

$ umask
0002

If I changed my umask to something else we can repeat this test a 3rd time and see the effects that umask has on the un-preserved cp:

$ umask 037
$ rm somedir/afile 

$ cp --no-preserve=all afile somedir/
$ ls -l somedir/
total 0
-rw-r-----. 1 saml saml 0 Feb 14 15:29 afile

Notice the permissions are no longer 664, but are 640? That was dictated by the umask. It was telling any commands that create a file to disable the lower 5 bits in the permissions ... these guys: (----wxrwx).