Make a group part of another group possible?

S

SamKook

To avoid having to make some users part of multiple groups(for nfs, makes things more tedious to add many instead of one for example), I was wondering if there was a way to have a group be part of another group or if only users can be part of groups.
Basically, having groupA have access to everything groupB and groupC have access to or something similar to that result.

Or, alternatively, have a specific folder have 2 different group permissions since I need some folders to have a specific more restricted group for stuff and I still want a more broad group of users to have access to that same folder and more.
For example, groupB has write access to /project/dev and groupC has write access to /project and all of its subfolders, which need to include /project/dev which groupB owns.

As far as I'm aware, neither of those seem to be possible, but I'd love to be wrong on this.
A user would need to be both part of groupB and groupC for what I want to work is my understanding.
 
SamKook said:
Or, alternatively, have a specific folder have 2 different group permissions since I need some folders to have a specific more restricted group for stuff and I still want a more broad group of users to have access to that same folder and more.
Click to expand...

This may be done with Access Control List. If you are using ZFS, it will accept NFSv4 ACLs. So

setfacl -m g:staff:full_set,g:user:write_set,g:visitor:read_set some_dir

will set different access permissions to different group to the directory some_dir.
Read setfacl(1).
 
Hiroo Ono said:
This may be done with Access Control List. If you are using ZFS, it will accept NFSv4 ACLs. So

setfacl -m g:staff:full_set,g:user:write_set,g:visitor:read_set some_dir

will set different access permissions to different group to the directory some_dir.
Read setfacl(1).
Click to expand...
Exactly. The user/group mechanism is very simple, and covers 90% or 95% of all use cases. In that sense it is genius, and typical Unix: a quick hack that gives us an MVP (minimum viable product). Other minicomputer operating systems of the same vintage had somewhat more complex user/group mechanisms (VMS for example has four categories: user/group/world/system, and four permissions, read/write/execute/delete). All of this works for "small workgroups", given the typical target machine of these operating systems, which was minicomputers that could handle 10-20 people at a time.

When you go to large systems (mainframes), the protection systems were much more complex. For example, IBM had RACF at about the same time the first Unix was written. A lot of that was inspired by Multics, which had much richer ways to express resource protections. Once Unix machines grew larger file servers (which is roughly when Sun, NetApp and NSF come in), it was quickly found that ACLs (from Multics and RACF) would be a good way to handle this.

The problem with ACLs is that they quickly become so complex. If you have hundreds of thousands of files, hundreds of users and groups, and each file has an ACL with a dozen ACE entries, managing this becomes an absolute nightmare. You end up having to build a system that is based on policy and auditing, which sets and changes ACLs. I don't know of any premade systems of that type, but they must exist.

So here's my advice: If you have to use ACLs, keep them as simple as possible. For example, deploy them just on a few "chokepoint" directories, and don't allow your users to set their own ACLs. The complexity can quickly overwhelm you.
 
The goal was to make things simpler so hopefully I can avoid having to resort to ACLs.
Things are working as I want them to so far making use of 2 groups for nfs shares(we can specify multiple groups per share even for v3 stuff so that helps) and the everyone permission so hopefully that keeps being the case as I finish setting everything up.
Good to know there is an alternative though.

Having groups be able to be part of groups just made sense to me for a simple system, but I guess they didn't think of that back when it was implemented.
 
ralphbsz said:
Exactly. The user/group mechanism is very simple, and covers 90% or 95% of all use cases. In that sense it is genius, and typical Unix: a quick hack that gives us an MVP (minimum viable product). Other minicomputer operating systems of the same vintage had somewhat more complex user/group mechanisms (VMS for example has four categories: user/group/world/system, and four permissions, read/write/execute/delete). All of this works for "small workgroups", given the typical target machine of these operating systems, which was minicomputers that could handle 10-20 people at a time.

When you go to large systems (mainframes), the protection systems were much more complex. For example, IBM had RACF at about the same time the first Unix was written. A lot of that was inspired by Multics, which had much richer ways to express resource protections. Once Unix machines grew larger file servers (which is roughly when Sun, NetApp and NSF come in), it was quickly found that ACLs (from Multics and RACF) would be a good way to handle this.

The problem with ACLs is that they quickly become so complex. If you have hundreds of thousands of files, hundreds of users and groups, and each file has an ACL with a dozen ACE entries, managing this becomes an absolute nightmare. You end up having to build a system that is based on policy and auditing, which sets and changes ACLs. I don't know of any premade systems of that type, but they must exist.

So here's my advice: If you have to use ACLs, keep them as simple as possible. For example, deploy them just on a few "chokepoint" directories, and don't allow your users to set their own ACLs. The complexity can quickly overwhelm you.
Click to expand...
VMS...!
If I recall correctly, it has default filesystem having versioning and needed `purge` (or `pur`) to purge unneeded old versions.
But accessing to its filesystem via Fortran (!) was quite a huge pain.
 
You must log in or register to reply here.
Back
Top