Allow group to r/w in folder owned by a specific user

Question

I have a group manager and an user user1.

user1 will create a directory by example in the webserver path /var/www/user1Project.

How to allow the group manager to r/w in any directory owned by user1 ?

I already tried to add group manager to user1. But it did not solved my problem. A user from manager group is not allowed to write in user1Project. I do not know why.

Solution 1

This is quite special and you could not manage this by using the legacy permissions architecture of an unixoid system. The closest approach to your intention is using ACLs. Issue the following command (optionally as superuser):

setfacl -d -R -m g:manager:rwx /dir/of/user1
setfacl -R -m g:manager:rwx /dir/of/user1

The first command sets the default permissions to the directory so that they apply to newly created files (by user1). The second command sets the actual rights of the folders and files recursively.

Note, that the ACL infrastructure does not apply to the Apache Webserver. Apache only cares about the legacy permissions (user/group/others permission). So inside the webfolder every file/folder must be in the www-data group and every file must have at least read permissions for www-data. Folders should have the execute permissions for www-data for the Index searching.

Update:

To force the newly created files inside a directory to inherit the group of this directory set the gid bit of the directory:

chmod g+s /web/directory

Newly created files inside /web/directory will then inherit the group of /web/directory

Solution 2

In addition to being part of the group, you have to set write permission on the directory:

 chmod 770 /var/www/user1Project/example_dir

(use 775 if you want the world to have read permission, which is more likely on a web directory).

Also realise that the user manager has to re-login after being added to the group user1.

If you want every directory created by user1 to be writeable by the group members of group user1, you can set:

umask 0002

which will result in directories created with permissions rwxrwxr-x.

Solution 3

When user1 creates the dir, it will be owned by user1:user1. This means user:group. Assuming they are in the same group, let's call it group1, user1 needs to make the group group1 the group owner of this directory. So:

chown :group1 dir`

Now for the manager to be able to r/w directories, the group permission bits need to be set to 7, ie rwx. This is done so:

chmod g+rwx dir

But, when manager creates a file it is owned by manager:manager, so he needs to chown it to :group1 for the group permissions to apply to group1, the same way user1 had to do.

There's a trick that copies the group ownership from the parent dir. It's the special group permission bit, SGID. This can be done so:

chmod g+s dir

Finally, newly created items (files and directories) take on the permissions from their parents, plus there's a last modifier called umask. It inverts single bits of permissions if they are set, and has the same format of 4 octal digits. Usually it is 0002 or 0022. 0002 means the second bit from the right will be masked (or inverted). For example, with umask 0022, when you create a new dir in another dir with permissions rwxrwxrwx, the new dir will get permissions rwxr-xr-x.

So if manager has umask 0022, he will also have to chmod his dirs and files to 7 to give the group full access to them.

Solution 4

Set directory group to manager:

chgrp -hR manager /your/target/directory/path

And then, add set-GID-bit to your permission, so if user1 changes anything, the group will be able to write again:

chmod g+s /your/target/directory/path

Solution 5

setfacl looks the best deal for you. Make sure that acl utilities are installed. To check if it is already installed

In Redhat bases systems do :

yum list acl

In Debian based systems do

dpkg -l acl

If not already installed, for Redhat bases systems do :

yum install acl.x86_64 # Or use dnf for later versions of Fedora and so

In Debian based systems do

dpkg install acl

Enable acl on the file systems, my modifying the /etc/fstab

UUID=your_uuid_here   /partition    filesystemtype   options,acl   0   2

Note ,acl is the only part added, now remount the partition

mount -o remount /your_partition_here

^{(That completes the setup part, you might not do this if acl already installed).}

---

Applyting setfacl

setfacl -m g:manager:rw file /var/www/user1Project #you need root privileges

You're good to go

View more solutions

Comments

[Admin]

You have two options (or even more), first: add maganer to user1 groups, 2nd: add an ACL for specific file or directory. Which one is what you want? You can also use chgrp -G or use GID-bits for permissions. Tell us what limitations you wanna set, and what you have tried.

[countermode]

the problem description is incomplete: How much do you want to automate the process? I.e. is user1 supposed to do anything manually? Second, should the sought solution apply to any directory that user1 creates, or only to selected directories (say, directories within a subtree of a file system)? Third, how does user1 create the directories under consideration - manually through mkdir on the command line, or from the desktop, or by a script?

[countermode]

Adding user1 to manager is not sufficient because newly created resources will assume the primary GID of the creating process by default.

[Atnaize]

@Gilles I posted another post on another forum and found a solution. serverfault.com/questions/796224/…

[Atnaize]

Is there any way to automate this cmd? Because I will not be aware when user1 will create a new folder

[Anthon]

You can set the umask, I'll update my answer.

[fragwürdig]

that is right - x then will be applied to all folders recusively but not to the files. sorry for that...

[Atnaize]

Is it possible to also inherit the parent's folder permission in addition to the group?

[ilkkachu]

setfacl -R -m g:... perhaps. At least on Linux setfacl doesn't like mixing the parameters the way you did (-R would be an argument to -m). I think user1 should also be able to add the ACL to their directory, so using superuser powers may not be necessary.

[ilkkachu]

Newly created files take permissions from the system call creating them, not their parent (except if you mean ACL:s, but you didn't mention them.) Also, umask doesn't invert any bits, it clears (masks) them. Inverting would imply that a zero could also turn into a one. (though I guess "inhibit" could be used in the same sense here, but it doesn't feel usual in this context.)

[Admin]

"It inverts single bits of permissions if they are set". Read carefully please. As for the system calls, I'm not that advanced.