Users and User Groups

In Unix-like operating systems, access to files, processes, and system services is controlled through users and groups.

In Unix-like operating systems, access to files, processes, and system services is controlled through users and groups. Every process runs under a specific user identity, and every file has an owning user and group. These ownership relationships form the foundation of Linux permissions and allow administrators to isolate workloads, delegate access, and maintain a clear security boundary.
A user is an individual identity within the system. Each account has a unique username and a numerical user ID (UID). The system uses the UID—not the display name—to make authorization decisions.

Linux accounts generally fall into several categories:

  • The superuser: The root account has UID 0 and unrestricted access to the system. Because it can read or modify any file and bypass most permission checks, it should be used only when necessary.
  • System accounts: These identities run services such as web servers, databases, or monitoring agents. They usually have no login shell and often have low UIDs assigned by the operating system.
  • Regular accounts: These are intended for administrators, developers, and ordinary application workloads. Their permissions are limited to the files and resources granted to them.

A group is a collection of users that can share access to the same resources. Each group has a unique group ID (GID). Users have one primary group, which determines the group ownership of newly created files, and may belong to any number of supplementary groups. Supplementary groups are especially useful for project-based collaboration.

For example, a developer might have developer as their primary group and belong to both deploy and project-web as supplementary groups. This lets the administrator grant access to shared code and deployment directories without making every collaborator an administrator.

Creating and Managing Users

On Linux, useradd creates a local user account. The -m option creates a home directory, while -s defines the default login shell:

sudo useradd -m -s /bin/bash developer

A newly created account is normally locked for password-based login until a password is configured:

sudo passwd developer

For systems that support centralized authentication, an administrator may instead assign a password through the relevant identity-management service.

Existing account properties can be changed with usermod:

# Change the default shell
sudo usermod -s /bin/sh developer

# Lock the account
sudo usermod -L developer

# Unlock the account
sudo usermod -U developer

The home directory and other stored attributes can also be updated with usermod, although moving an active user's home directory requires additional care.

To remove an account, use userdel:

sudo userdel developer

The -r option also requests removal of the user's home directory and mail spool:

sudo userdel -r developer

Before deleting an account, verify that it has no running processes and does not own important files. In production environments, removing the account and retaining its data for audit or recovery may be preferable.

Managing Groups

Use groupadd to create a group:

sudo groupadd devops

Users can be added to a supplementary group with usermod:

sudo usermod -aG devops developer

The -a option is essential because it appends the user to the specified supplementary groups. Without it, usermod -G can replace the user's existing supplementary group memberships.

The -G option creates a group with a specific GID:

sudo groupadd -g 2000 devops

To change a user's primary group, use:

sudo usermod -g devops developer

After group membership changes, the user should start a new login session for the updated memberships to take effect. To review current identities and groups, run:

id developer
groups developer

Groups can be removed with groupdel:

sudo groupdel devops

A group cannot be deleted if it is still the primary group of an existing account. Before removing it, identify affected users and assign them a different primary group.

File Ownership and Permissions

Linux permissions distinguish three categories:

  • The owner
  • The group
  • others

A permission such as rwxr-x--- grants full access to the owner, read and execute access to the group, and no access to others. Directory permissions also control the ability to list names, traverse the directory, and create or delete entries.

Suppose a project directory should be shared by members of the project-web group:

sudo chgrp -R project-web /srv/project-web
sudo chmod -R 2770 /srv/project-web

The leading 2 enables the setgid bit, causing new files and directories to inherit the directory's group. The setgid bit can also be applied directly to a directory:

sudo chmod g+s /srv/project-web

This model is more maintainable than changing ownership for every individual user. When access requirements change, an administrator can update the group's permissions or membership in one place.

Security Best Practices

Effective account management follows several core practices:

  1. Apply the principle of least privilege. Perform routine development and administrative work with regular accounts. Use sudo for specific commands that genuinely require elevated privileges rather than working permanently as root.

  2. Use separate service accounts. Each service should run under its own identity. If one service is compromised, the attacker should not automatically gain the privileges of every other service.

  3. Prefer group-based access. Create groups for shared responsibilities and grant permissions to those groups instead of assigning broad access to individual accounts.

  4. Disable unused accounts promptly. Dormant credentials can become an entry point for attackers. Remove them when they are no longer required, and use account lockout rather than deletion when temporary suspension is appropriate.

  5. Audit memberships and privileges. Review local account databases such as /etc/passwd and /etc/group, along with sudoers policies and group memberships. In environments using LDAP, Active Directory, or another directory service, audit the central source as well.

  6. Protect account credentials. Require strong passwords or, where supported, multi-factor authentication. Avoid storing plaintext credentials in scripts, repositories, or configuration files.

  7. Control home-directory permissions. Personal directories should generally be accessible only to their owners unless shared access is explicitly required.

  8. Test changes carefully. Commands involving recursive deletion, ownership changes, or permission updates can affect large portions of a system. Verify the target path and review the resulting ownership with commands such as ls -ld and namei.

By assigning identities deliberately, organizing access around groups, and reviewing permissions regularly, administrators can create a Linux environment that supports collaboration without exposing every user to full administrative control.