Why group management matters

Groups allow you to manage permissions for sets of users instead of individuals. Instead of giving access user-by-user, you assign permissions to a group and add users to it. This is critical for maintainable access control on any multi-user Solaris system.

In this lesson you will learn how to create groups, add users to them, and use groups to control access to shared directories.

Group-management concepts

Primary vs supplementary groups

Every user has one primary group recorded in /etc/passwd, and may belong to multiple supplementary groups recorded in /etc/group.

Access control

Directory and file permissions are often granted to a group, and all members of that group inherit the same level of access.

Project / application groups

It is common to create one group per project or application team so that ownership and access are easy to reason about.

Step-by-step group-management commands

Use the following commands in your Solaris lab VM to understand how groups are stored and how they affect access to shared directories.

1. View existing groups

Start by looking at /etc/group to understand which groups already exist on the system.

terminal — bash

solaris-lab

[root@solaris ~]# tail -7 /etc/group
bin::2:root,bin
sys::3:root,uucp
adm::4:root,adm,daemon
daemon::1:root,daemon
staff::10:
dba::60:oracle
appteam::80:devuser,appuser

2. Create a new group

Use groupadd to create a new application or project group with a specific GID (optional).

terminal — bash

solaris-lab

[root@solaris ~]# groupadd -g 81 webteam
 
[root@solaris ~]# getent group webteam
webteam::81:

3. Add an existing user to a secondary group

Use usermod -G (or -a -G depending on OS) to set the list of supplementary groups. On Solaris, -G replaces the list.

terminal — bash

solaris-lab

[root@solaris ~]# id appuser
uid=1101(appuser) gid=10(staff) groups=10(staff)
 
[root@solaris ~]# usermod -G staff,webteam appuser
 
[root@solaris ~]# id appuser
uid=1101(appuser) gid=10(staff) groups=10(staff),81(webteam)

4. Verify group membership as that user

Use su - to switch to the user and check groups from their perspective.

terminal — bash

solaris-lab

[root@solaris ~]# su - appuser
Oracle Corporation      SunOS 5.11      Solaris 11.4
 
[appuser@solaris ~]$ groups
staff webteam
 
[appuser@solaris ~]$ id
uid=1101(appuser) gid=10(staff) groups=10(staff),81(webteam)

5. Use groups for directory access

Create a shared directory owned by the group and give group write access so all team members can collaborate.

terminal — bash

solaris-lab

[root@solaris ~]# mkdir -p /projects/webapp
[root@solaris ~]# chown root:webteam /projects/webapp
[root@solaris ~]# chmod 2775 /projects/webapp
 
[root@solaris ~]# ls -ld /projects/webapp
drwxrwsr-x   2 root  webteam      2 Jan 11 11:30 /projects/webapp
 
[appuser@solaris ~]$ cd /projects/webapp
[appuser@solaris /projects/webapp]$ touch testfile
[appuser@solaris /projects/webapp]$ ls -l
-rw-r--r--   1 appuser  webteam     0 Jan 11 11:31 testfile

6. Rename or remove a group

You can change group attributes with groupmod and remove unused groups with groupdel.

terminal — bash

solaris-lab

[root@solaris ~]# groupmod -n webteam_legacy webteam
 
[root@solaris ~]# getent group webteam_legacy
webteam_legacy::81:appuser
 
# Remove a group only after cleaning up membership:
[root@solaris ~]# groupdel webteam_legacy

Good practices for groups and shared directories

Designing groups

Create groups based on roles or applications, not individual users.
Avoid reusing the same group for unrelated purposes; it becomes hard to reason about permissions.
Use consistent naming such as appteam, dbteam, backupops, etc.

Managing shared folders

Use the setgid bit (chmod 2775) on shared directories so new files inherit the directory's group.
Ensure that only the correct group has write access to shared folders.
Regularly review group membership, especially when people change teams or leave the organisation.

Practice task – groups for a small project team

Create a group called projectx and add two users to it (for example, devuser and opsuser).

Create /projects/projectx, set its group ownership to projectx and apply chmod 2775.

Finally, remove one user from the group and confirm that access changes as expected.

In upcoming lessons, we will build on users and groups when we talk about permissions, services and real-world troubleshooting.