Linux Users, Groups, and Permissions

Key Takeaways

• Ownership and permissions work together: each file has an owner, a group, and access rules for owner, group, and others.
• Groups simplify shared access, but changing membership doesn't update credentials in already-running processes.
• Use sudo for authorized administrative commands rather than routinely working in a root shell.
• Directory traversal, ACLs, and security policy can explain access failures that file mode bits alone don't reveal.

Linux users, groups, and permissions determine which identities can access files and perform administrative work. Use groups to organize shared access, chmod to change permission bits, and chown to change ownership; use sudo only when the task requires privileges your account doesn't have.

The examples below target common Debian/Ubuntu and RHEL/Fedora installations. Replace alice, project, and example paths with your own values; don't type angle brackets around replacements. Account-changing commands assume you already have administrative authorization. Practice destructive operations on a disposable machine.

Linux Users: Accounts, UIDs, and Roles

An account has a numeric user ID, or UID, and a primary group ID, or GID. Names make these identifiers readable; filesystem ownership ultimately refers to the numbers. System and regular accounts are administrative conventions, not separate kernel account types, and their allocation ranges depend on distribution and configuration.

System users

System accounts give services separate identities. They may have home directories; restricting interactive login and granting only necessary access matters more than whether a home directory exists.

Regular users

Regular accounts normally represent people and provide an interactive shell and home directory. Don't infer an account's privileges from its username or UID range alone.

The root user

Root has UID 0. Root processes normally have capabilities—individual privileged powers—that bypass many ordinary permission checks. Authorized administrators can manage accounts through sudo without logging in directly as root.

Viewing local and directory-backed accounts

cat /etc/passwd
getent passwd
getent passwd alice

/etc/passwd contains local account records. getent queries the configured Name Service Switch, or NSS, which can also resolve directory-backed accounts. Some backends disable enumeration, so getent passwd isn't guaranteed to list every resolvable account; a named lookup is often more useful.

Each passwd record contains seven colon-separated fields: username, password field, UID, primary GID, comment/GECOS, home directory, and login shell. An x in the password field indicates that the password hash is stored in /etc/shadow.

su vs sudo: Switching Identity and Running Commands

su starts a shell under another identity; without a username, it targets root. sudo runs a command as an identity allowed by policy, normally root unless another target is selected. Neither command is limited to switching from an ordinary account to root.

# Run one command as another user, if authorized.
sudo -u alice id

# Inspect your sudo authorization.
sudo -l

Switching to root or another user

Use sudo -i when you genuinely need a root login shell, then exit promptly. Use su - when root-password authentication is available. The hyphen requests a login-style environment; sudo su adds an unnecessary intermediate step for this purpose.

Ubuntu commonly ships with root password authentication locked, not with the root account absent. An administrator can set a root password with sudo passwd root, but ordinary sudo administration doesn't require doing so. Local policy and installation choices can differ.

Editing sudoers safely

Authorization can come from user rules, group rules, and included configuration such as /etc/sudoers.d/. The sudo group is common on Debian/Ubuntu; RHEL/Fedora commonly use wheel. Group membership grants sudo access only when the policy authorizes that group.

Use visudo, not an ordinary direct edit, to change sudoers configuration. It locks the file and checks syntax; -f selects a drop-in file, while -c checks the complete configured policy.

sudo visudo

# Alternative: edit a drop-in when sudoers includes this directory.
sudo visudo -f /etc/sudoers.d/local-admins

# Validate the complete configuration afterward.
sudo visudo -c

Adding, Testing, and Removing Linux Users

Adding a user

On Debian/Ubuntu, the interactive adduser helper is usually the beginner-friendly choice. It creates the account and home directory and prompts for a password and account information.

sudo adduser alice

On systems using shadow-utils, including common RHEL/Fedora installations, make the important choices explicit. Run this alternative only if alice doesn't already exist and /bin/bash is installed:

sudo useradd -m -U -s /bin/bash alice
sudo passwd alice

-m creates the home directory, -U creates a same-named primary group, and -s selects the login shell. Bare useradd alice doesn't reliably provide these interactive defaults across distributions. passwd prompts for the initial password rather than placing it in your command line.

Logging in as the new user

su - alice
id
exit

An unprivileged caller normally authenticates with the target user's password. Root can normally switch without that password, but PAM—the system's configurable authentication framework—and local policy control the actual requirements. su - alice starts a login-style shell, not a complete equivalent of a fresh desktop or SSH login session.

Removing a user without losing track of data

Before deletion, record the UID, inventory owned files outside the home directory, decide what to retain, and stop the account's sessions and services. userdel normally refuses deletion while the account owns running processes; don't bypass that protection casually.

For temporary password locking, use sudo passwd -l alice. This locks password authentication, not every login method: SSH keys may still work, and existing processes aren't terminated. Offboarding therefore requires checking all relevant access methods.

# Remove the account while retaining its home directory.
sudo userdel alice

The destructive alternative is sudo userdel -r alice, which also removes the home directory and mail spool. It doesn't clean up every file owned elsewhere. Retained files still carry numeric ownership, so later UID reuse can expose them to an unrelated account.

Linux Groups: Primary and Supplementary Membership

Each account has a primary group and can have supplementary groups for additional access. New files normally use the creating process's effective group; a setgid parent directory can instead supply its group.

cat /etc/group
getent group
getent group project
id alice
groups alice

/etc/group contains local records; getent group uses NSS. A group's listed members aren't a complete account-membership report, particularly for primary membership or directory-backed identities. Use id alice or groups alice to inspect the account's memberships.

For local accounts on common Debian/Ubuntu and RHEL/Fedora systems, create a project group and append alice to it:

sudo groupadd project
sudo usermod -aG project alice
id alice

-G specifies supplementary groups; -a appends rather than replacing the existing list. Omitting -a can remove memberships you didn't name, including an administrative group. Start a new login session afterward; existing processes retain their old group credentials.

To remove this supplementary membership later, use sudo gpasswd -d alice project. Change directory-managed memberships in the identity service rather than with local account tools.

Reading Linux File Permissions with ls -l

Run ls -l file.txt to inspect ownership and permissions. A long listing can look like this; the names, size, and timestamp are illustrative.

-rw-r--r-- 1 alice project 1234 Oct 17 10:00 file.txt

-  rw-  r--  r--
|   |    |    |
|   |    |    +-- others: read
|   |    +------- group: read
|   +------------ owner: read and write
+---------------- file type: regular file

The first character identifies the file type: - means a regular file, d a directory, and l a symbolic link. The next nine positions form owner, group, and other triplets, with r for read, w for write, x for execute, and - for an absent permission.

Therefore, -rw-r--r-- gives the owner read/write access and gives the group and others read access. In contrast, -rwxr--r-- also grants the owner execute permission. The remaining listing fields show link count, owner, group, size, modification time, and name.

Which permission triplet applies?

For ordinary mode-bit checks without an extended ACL, Linux first checks whether the process owns the file. Otherwise it checks matching group membership, then falls back to others. These permissions aren't added together: an owner denied access doesn't fall through to a more permissive others triplet.

Special permission bits

• Setuid and setgid: On executable binaries, these can change the effective user or group identity during execution. Don't add them casually.
• Directory setgid: Newly created entries inherit the directory's group. This doesn't itself grant group write access.
• Sticky bit: Restricts who can remove or rename entries in a shared directory, typically to the entry owner, directory owner, or a privileged process.

In ls output, s/S replaces the owner or group execute position for setuid/setgid, and t/T replaces the others execute position for sticky. Uppercase means the corresponding execute bit isn't set.

Directory Permissions Are Different

To read /srv/project/report.txt, a process needs search permission on /, /srv, and /srv/project, plus read permission on report.txt. Directory read permission alone doesn't allow traversal. Removing a file depends mainly on its parent directory's permissions, not whether the file itself is writable; sticky-bit restrictions can also apply.

For a regular file, x permits execution; it doesn't supply a valid program or interpreter. Directly executing a script also requires an appropriate interpreter and executable path, and a noexec mount can prevent execution.

Changing Permissions with chmod

The file owner or an appropriately privileged administrator can change mode bits. You don't need sudo merely because you're using chmod. In symbolic modes, u means owner, g group, o others, and a all three; + adds, - removes, and = assigns permissions.

Work in a new directory you own. These examples first modify selected classes, then set a specific final mode:

mkdir permissions-lab
cd permissions-lab
touch file.txt

chmod u+rw file.txt
chmod ug+rw file.txt
chmod go-rw file.txt
chmod a-rwx file.txt
chmod u=rw,g=r,o= file.txt

# Equivalent ordinary permission bits:
chmod 640 file.txt
stat -c '%A %a %U:%G %n' file.txt

Numeric permissions: 640, 644, and 755

Numeric modes use octal digits: read = 4, write = 2, execute = 1. Add the values within each class, then write owner, group, and others in that order.

Choose permissions for the intended operation. A directory may need search permission where a data file doesn't need execute permission.

How umask affects permissions

umask is a process setting that removes permission bits when files are created. Without a default ACL, a requested file mode of 666 with umask 022 becomes 644; a requested directory mode of 777 becomes 755. The application still chooses the requested mode, so umask doesn't force every new file to have identical permissions.

There's also a chmod interaction: when you omit the class, as in chmod +rwx file.txt, umask filters which permission bits can change. Use explicit classes instead: chmod u+rw file.txt adds owner read/write, while chmod a-rwx file.txt removes all ordinary access bits.

Changing Ownership with chown and chgrp

These are alternative forms, not a sequence to run consecutively. Assume alice, project, and file.txt already exist:

# Change the owner; preserve the group.
sudo chown alice file.txt

# Change owner and group together.
sudo chown alice:project file.txt

# Change only the group.
sudo chown :project file.txt

# Another group-only form.
sudo chgrp project file.txt

Ordinary users generally can't give a file to another owner. A file owner can change its group to a group they belong to; that case doesn't require sudo.

-R applies ownership changes recursively. Before considering sudo chown -R alice:project /srv/project, verify the exact target, the tree's contents, and whether everything should share that ownership. Never use a broad recursive change to guess your way out of an access error.

ACLs and a Practical Access-Diagnosis Workflow

When mode bits aren't enough

An access control list, or ACL, can grant access to additional named users and groups. Use getfacl to inspect it and setfacl to modify it; install your distribution's ACL utilities if needed. On a file you own, after alice exists, this grants alice read access:

getfacl file.txt
setfacl -m u:alice:r file.txt
getfacl file.txt

Check effective permissions, not just the named entry: an ACL mask limits named-user and group-class access. With an extended ACL, the displayed group mode bits represent that mask, so chmod can affect ACL-granted access too.

Diagnosing Permission denied

For an existing file at /srv/project/report.txt, inspect identity, metadata, each path component, and the ACL:

id
id alice
stat -c '%A %a %U:%G %n' /srv/project/report.txt
namei -l /srv/project/report.txt
getfacl /srv/project/report.txt

id without a username reports the current process's credentials; id alice queries account information. stat shows symbolic mode, octal mode, owner/group, and filename with the format above. namei -l exposes permissions and ownership along the path, including intermediate directories.

If those checks pass, investigate the failing process's actual credentials and additional security controls. For SELinux-enabled systems, Red Hat's SELinux troubleshooting guide explains how to identify policy denials. Don't disable security controls or widen permissions before finding the cause.

Common Mistakes

• Using chmod 777 as a fix: It grants every class read, write, and execute permissions. Identify the required identity and operation instead.
• Running chmod -R 755 on mixed content: It also makes ordinary data files executable. Files and directories often need different modes.
• Working routinely as root: Prefer a scoped sudo command and return to your ordinary account.
• Forgetting running processes: Updating account records doesn't refresh existing group credentials.

These follow directly from numeric-mode behavior, recursive chmod operation, and process-based credentials.

When you automate these steps, make target selection explicit. Our Bash getopts tutorial covers command-line option parsing, while An Introduction to Chef introduces configuration management for repeatable server setup.

FAQ

What does -rw-r--r-- mean in Linux?

It identifies a regular file whose owner can read and write it, while its group and everyone else can only read it. No execute bits are set.

How do I add a user to a group in Linux?

For a local account on systems using shadow-utils, run sudo usermod -aG project alice, replacing the group and username. Keep -a to preserve existing supplementary memberships, then start a new login session.

What is the difference between chmod 644 and chmod 755?

644 gives the owner read/write access and everyone else read access. 755 adds execute permission for all three classes; on directories, that bit permits search and traversal.

Why can't I access a file even though it has read permission?

Your process must match a permission class that grants read access and have search permission on every parent directory. ACL masks, outdated process group memberships, or additional security policy can also prevent access.

What is the difference between sudo and su?

sudo runs commands as an identity permitted by policy, commonly root, while su starts a shell under another identity. su normally requests the target user's password for an unprivileged caller; sudo authentication requirements come from its configured policy.

Further Reading

• Ubuntu Server: user management — local accounts, root authentication, and administrative groups.
• useradd manual — home directories, shells, groups, and configurable defaults.
• usermod manual — supplementary membership and account changes.
• GNU chmod documentation — permissions, privileges, and recursive changes.
• GNU chown documentation — owner/group syntax and recursive-operation risks.
• visudo manual — safe editing and complete-policy validation.
• Linux pathname resolution — traversal and permission selection.
• Linux ACL documentation — named entries, masks, and mode-bit relationships.