Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question

1 Answer 1

up vote 3 down vote accepted

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.

share|improve this answer
    
Thank you @aldavud so much. That explains the case. In fact, I should have read the doc more careful. It helps me understand the "strange" and examine some workarounds for the scenario as it would be on my own control. Thanks again! –  Ngoc Pham Nov 28 '12 at 0:35
    
What is the difference between "adding" and "creating"? Which system call do you think that cp and tar use? I'm pretty sure that cp and tar use open() or creat(). The reason that the mask is restrictive is that cp/tar supply a more restricted mode argument to open() and/or change the permissions afterwards with chmod()/fchmod() (the group perms are mapped to the mask). –  pelle Oct 15 at 8:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.