Default permission for newly-created files/folders using ACLs not respected by commands like "unzip"

I am having trouble with setting up a system for multiple users accessing the same set of files. I've read tuts and docs around and played with ACLs but haven't succeeded yet.

MY SCENARIO:

Have multiple users, for example, user1 and user2, which is belong to a group called sharedusers. They must have all WRITE permission to a same set of files and directories, say underlying in /userdata/sharing/.

I have the folder's group set to sharedusers and SGID to have all newly created files/dirs inside set to same group.

ubuntu@home:/userdata$  ll
drwxr-sr-x  2 ubuntu sharedusers 4096 Nov 24 03:51 sharing/

I set ACLs for this directory so I can have permission of sub dirs/files inheritted from its parents.

ubuntu@home:/userdata$  setfacl -m group:sharedusers:rwx sharing/
ubuntu@home:/userdata$  setfacl -d -m group:sharedusers:rwx sharing/

Here's what I've got:

ubuntu@home:/userdata$   getfacl sharing/
# file: sharing/
# owner: ubuntu
# group: sharedusers
# flags: -s-
user::rwx
group::r-x
group:sharedusers:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:sharedusers:rwx
default:mask::rwx
default:other::r-x

Seems okay as when I create new folder with new files inside and the permission is correct.

ubuntu@home:/userdata/sharing$ mkdir a && cd a
ubuntu@home:/userdata/sharing/a$ touch a_test
ubuntu@home:/userdata/sharing/a$  getfacl a_test 
# file: a_test
# owner: ubuntu
# group: sharedusers
user::rw-
group::r-x                  #effective:r--
group:sharedusers:rwx       #effective:rw-
mask::rw-
other::r--

As you can see, the sharedusers group has effective permission rw-.

HOWEVER, if I have a zip file, and use unzip -q command to unzip the file inside the folder sharing, the extracted folders don't have group write permisison. Therefore, the users from group sharedusers cannot modify files under those extracted folders.

ubuntu@home:/userdata/sharing$  unzip -q Joomla_3.0.2-Stable-Full_Package.zip 
ubuntu@home:/userdata/sharing$  ll
drwxrwsr-x+  2 ubuntu sharedusers    4096 Nov 24 04:00 a/
drwxr-xr-x+ 10 ubuntu sharedusers    4096 Nov  7 01:52 administrator/
drwxr-xr-x+ 13 ubuntu sharedusers    4096 Nov  7 01:52 components/

You an spot the difference in permissions between folder a (created before) and folder administrator extracted by unzip. And the ACLs of a files inside administrator:

ubuntu@home:/userdata/sharing$  getfacl administrator/index.php 
# file: administrator/index.php
# owner: ubuntu
# group: ubuntu
user::rw-
group::r-x                #effective:r--
group:sharedusers:rwx     #effective:r--
mask::r--
other::r--

It also has ubuntu group, not sharedusers group as expected.

Could someone please explain the problem and give me advice? Thank you in advance!

This behavior is the ACL_MASK at work. Looking at the index.php file, it does theoretically get the intended permission group:sharedusers:rwx, but effectively another one #effective:r--. This is because the theoretic value gets XOR'd with the mask::r-- to give the effective one, which is what you see with ls -l (or ll).

Now the ACL_MASK of mask::r-- is in fact a security feature of ACL, keeping you from giving access where you didn't intend to: When adding an existing file (as opposed to creating a new one), ACL sets the ACL_MASK to the former value of the file, which in this case was r--.

This isn't limited to unzip. This applies whenever you add a file as opposed to create it. You could try cp or tar for example, and would end up with the same result.

In fact the documentation (man 5 acl) states in the paragraph OBJECT CREATION AND DEFAULT ACLs that the default values only apply for object created with any of the following system calls: creat(), mkdir(), mknod(), mkfifo(), or open().

Therefore I can't give you a good solution, as you won't be able to use the ACL default mechanism for what you're doing.