Linux – How to create a hierarchy of UNIX groups as below

aclldaplinuxpermissions

I need to create a hierarchy of UNIX groups. Something like below:

A
|\
| \
B  c
|\
D e
|\
f g

…where A, B and D are UNIX groups and c,e,f and g are UNIX accounts that are members of those specific groups. I have googled a lot but it seems that this is not possible.

Currently, we have the following:

Group A has members c.
Group B has members e.
Group D has members f,g.

UPDATE:

@John's post made me realize that I needed to re-frame my requirements to remove the ambiguity.

What I require is:

Limit access to a directory only to members of group B (so B is
group owner of that folder). As group D is a sub-group of B, members of D would be members of group B and have access to that directory as well.
But members of Group B needs to have the same rights as members of group A. (So if group A is a directory group owner then automatically group B is the directory group-owner).

By the way, this is a real-world problem where I have full control over group B and its members; and limited or no control over other groups and their members. So I cannot create new groups and give membership to members from group A or D.

Best Answer

With normal unix permissions, you can't do this.

With ACLs you can (or should be able to).

You need to be using a filesystem that supports ACLs. Most modern linux filesystems do.

The basic command is setfacl

In your example, if group B owns directory /B you would add access rights for group D as follows:

setfacl -m group:B:rwx,group:D:rwx /B

This is only the most basic example but might get the idea across. This does require careful and explicit setting of access control, but can do much more than basic unix permissions. It isn't nearly as capable as, as full AD group policy and the like, though.

Here's some documentation of ACLs in general

Related Solutions

Granting write permissions to a group to a folder

Granting 775 permissions on a directory doesn't automatically mean that all users in a certain group will gain rwx access to it. They need to either be the owner of the directory or to belong to the directory's group:

$ ls -ld some_dir
drwxrwxr-x 2 alex consult 4096 Feb 20 10:10 some_dir/
              ^     ^
              |     |_____ directory's group
              |___________ directory's owner

So, in order to allow both alex and ben to have write access to some_dir, the some_dir directory itself must belong to the consult group. If that's not the case, the directory's owner (alex in your example), should issue the following command:

$ chgrp consult some_dir/

or to change group ownership of everything inside the directory:

$ chgrp -R consult some_dir/

This will only work if alex is a member of the consult group, which seems to be the case in your example.

This will not allow ben to access all of alex's directories for two reasons:

Not all of alex's directories will belong to the consult group
Some of alex's directories may belong to the consult group but alex may not have chosen to allow rwx group access to them.

In short, the answer depends both on group ownership and on the group permission bits set for the directory.

All of this is provided you don't use any additional mandatory access control measures on your system.

Precedence of ACLS when a user belongs to multiple groups

From the standard:

In words, Common Access Determination Algorithm is to be interpreted as follows (this description is a loose paraphrase of the common access determination algorithm which is specified in detailed pseudocode in ACL Managers ):

Match (in the sense defined in the pseudocode in ACL Managers ) the incoming PAC against the ACL's access ACLEs (in the top-to-bottom order shown, namely: UO, U, FU, GO/G/FG, O, FO, AO), stopping at the first such match (except that all matches are considered "simultaneously" in the case of the indicated group-like ACLEs), and note the permissions granted by the matched ACLE (or, in the case of the group-like ACLEs, the union of the permissions granted by all the matched ACLEs).

Mask (that is, intersect) the acquired permissions against the permissions in the ACL's mask ACLEs, as necessary (namely, mask with MASK_OBJ permissions if the match occurred in the center column¹, and/or mask with UNAUTHENTICATED permissions if the PAC is unauthenticated). (If the ACL Manager doesn't support these two mask ACLEs, this step is a null operation.)

(emphasis in original, footnote added)

That is, if there is a file with user and group root and permissions 0600 called acl-test, containing the single line read possible, then:

$ getfacl acl-test
# file acl-test
# owner: root
# group: root
user::rw-
group::---
other::---

Now if I (as user fox) attempt to cat this:

$ cat acl-test
cat: acl-test: Permission denied

Group permissions are unioned

I happen to be in the groups users and wheel, so we can add specific ACLs for these groups:

# setfacl -m g:users:--- -m g:wheel:r-- acl-test
$ cat acl-test
read possible

This is because the group entries (considered simultaneously) allow read permission to one of my groups. These can be combined:

# setfacl -m g:users:-w- acl-test
$ getfacl acl-test
# file: acl-test
# owner: root
# group: root
user::rw-
group::---
group:wheel:r--
group:users:-w-
mask::rw-
other::---
$ printf '%s\n' 'write possible' >> acl-test
$ cat acl-test
read possible
write possible

So now I can both read and write the file, even though the groups that allow these permissions are not the same group.

User-specific permissions override all groups

Since user rules apply before group rules, we can still restrict a given user from reading and/or writing contents:

# setfacl -m u:fox:--- acl-test
$ getfacl acl-test
# file: acl-test
# owner: root
# group: root
user::rw-
user:fox:---
group::---
group:wheel:r--
group:users:-w-
mask::rw-
other::---
$ cat acl-test
cat: acl-test: Permission denied

A mask, if set, overrides almost everything

If a file is meant to be truly read-only to anyone but the owner:

# setfacl -x u:fox -m g::rw- -m m:r-- acl-test
$ getfacl acl-test
# file: acl-test
# owner: root
# group: root
user::rw-
group::rw-          #effective:r--
group:wheel:r--
group:users:-w-     #effective:---
mask::r--
other::---
$ printf '%s\n' 'now writing is impossible' >> acl-test
bash: acl-test: Permission denied
# printf '%s\n' 'owner can still write' >> acl-test

Amusingly, the mask does not override the others permissions, so:

# setfacl -x g:users -x g:wheel -m o:rw- -n acl-test
$ getfacl acl-test
# file: acl-test
# owner: root
# group: root
user::rw-
group::rw-          #effective:r--
mask::r--
other::rw-
$ printf '%s\n' 'others can write now' >> acl-test
# chown :users acl-test
$ printf '%s\n' 'but not members of the owning group' >> acl-test
bash: acl-test: Permission denied

¹ The "center column" refers to this image and contains everything except UO and O, so the owning user and others are unaffected by a mask. All groups and non-owning users with defined rules are affected.