Managing user accounts and permissions on Ubuntu

An Ubuntu desktop is a multi-user system even when one person appears to use it. A shared family computer, a second-hand laptop passed between relatives, or a small-business workstation can each contain files belonging to different people. Separate identities stop one user from casually reading another user’s documents, changing system settings, or installing software without authority.

Ubuntu normally locks the root account and gives day-to-day control to a named person through sudo. Each account has its own home directory, login credentials, group membership, and file permissions. That arrangement lets an authorised administrator maintain the system while ordinary sessions remain constrained. Central directory services can add another layer on workplace machines, but the local principles stay the same.

Good access control combines clear identities, sensible ownership, current software, and a recovery plan. It is rarely one magical setting. The work involves deciding who needs elevated rights, limiting those rights to a suitable period, reviewing access when roles change, and avoiding shared logins that make responsibility impossible to establish. The same care helps on Ubuntu Touch, where account controls differ from a desktop.

Why separate identities matter

User accounts do more than provide a login. They establish ownership, group access, home-directory boundaries, and audit trails. On a shared machine, an ordinary account can hold personal files while an administrator account handles packages and services. This separation limits accidental damage and makes suspicious activity easier to attribute to a person rather than to an anonymous “operator” account.

The distinction is useful in Australian community settings as well as workplaces. Around Melbourne, Linux meet-ups and the Ubuntu Australia community bring together people testing unfamiliar systems, sometimes on a shared spare machine. A “have a go” attitude suits that experimentation, yet each attendee still needs a recognisable account if files or settings are kept between sessions.

A safe look at sudo and root

Root is the traditional superuser, but Ubuntu normally prevents direct root login. Sudo grants a listed user temporary elevation after authentication. Useful checks include sudo -l, which lists permitted commands, and sudo -i, which starts a root login shell. sudo -s runs a shell with root privileges while retaining the current directory, so it is useful in scripts and troubleshooting.

Persistent policy belongs in sudoers, never in improvised direct edits. Use sudo visudo to open the file safely and check its syntax before saving. A malformed rule can lock administrators out of elevated operations. Reviewing current privileges with sudo -l is quicker than guessing which commands a particular account can run, especially after group membership changes.

Patching is part of the same security boundary because an outdated privileged service can undermine careful account controls. Ubuntu’s software update settings explains how automatic updates, manual checks, and restart prompts fit together, giving administrators a practical routine for keeping the base system current.

Creating and removing user accounts

sudo adduser alex is the straightforward route for a local person. It creates a home directory, copies basic configuration files, and prompts for account details. The new user receives an ordinary login unless separately granted administrative rights. A named account also gives SSH users a stable identity for keys and authorised access, provided remote login has been configured deliberately.

Adding an account does not automatically make it an administrator. sudo usermod -aG sudo alex adds the user to the sudo group; the -aG combination appends supplementary groups rather than replacing existing ones. Confirm the result with groups alex. Since membership in that group confers full administrative control, an approved administrator should grant it only where the job genuinely requires package installation or system-wide changes.

Before deleting someone’s account, check for work outside the home directory and preserve any records needed for audit or recovery. sudo userdel -r alex also removes the home directory and mail spool, so the -r option deserves care. Renaming an obsolete home directory can be safer while historical access is reviewed. Neither approach substitutes for a tested backup of important data.

Groups, roles, and access boundaries

Groups express shared access without repeating a rule for every file. Every account has a primary group and may belong to supplementary groups. Use id alex to see them. The newgrp plugdev command can add a group to the current shell session, while group membership added with usermod -aG normally takes effect at the next login.

Groups can control access to removable devices, printing, or specialised services, but their effects differ. Membership of the docker group can provide root-equivalent control over the host, so it should not be treated as a casual convenience group. Service accounts are another case: they often use /usr/sbin/nologin as their shell and run under a daemon rather than through an interactive password login.

Managed workplace machines may draw accounts from Active Directory, LDAP, or a hosted identity platform. Central role groups then apply consistent access across Australian offices in Sydney, Brisbane, or regional sites, while local exceptions remain possible. A synchronised identity still needs local privilege rules reviewed, especially where contractors change roles or leave while their network account remains temporarily cached.

Files, ownership, and permission modes

File access begins with ownership. ls -l shows the owner, group, and other permissions, represented by r for read, w for write, and x for execute. On directories, execute permission allows traversal, while read permission allows listing names. On regular files, execute has a different meaning and should be added only when the file needs to run.

Chmod changes permission bits, not ownership. The familiar chmod 644 file lets the owner read and write, lets the group read, and denies other users access; chmod 600 file limits it to the owner. For a private directory, chmod 700 permits its owner to list, enter, and modify entries. Symbolic modes such as u+x can make intent clearer when changing one part of a mode.

sudo chown alex:staff report.txt transfers both owner and group. Ownership and mode are separate controls, so changing one does not reliably fix a problem in the other. A home directory usually needs its owner to control it, often with mode 700 or 750. Altering files owned by a service can break that service, making a backup and a clear reason essential before applying chown.

Default access can be shaped with a umask. umask 077 normally creates private files and directories for the owner, whereas a shared working directory may need a carefully chosen group policy. POSIX access lists provide finer exceptions: setfacl -m u:bob:r-- notes.txt grants Bob read access without making the file world-readable. Use getfacl to inspect inherited and direct rules before changing them.

Passwords, locking, and account lifecycles

Password policy is more useful when it matches the account’s purpose. passwd alex changes a local password, and chage -M 90 -W 14 alex sets a maximum age and warning period for an existing account. A password manager can generate and store a long unique secret without putting it in a terminal history. Administrator credentials deserve the same treatment as other valuable logins.

Locking a password and disabling an account are different operations. passwd -l alex prevents password authentication, but an existing SSH key or active session may still work. Account expiry, a non-login shell, removal from privileged groups, and termination of active sessions may be needed together. chage -l alex and usermod -L alex help reveal or apply the relevant state.

Where pam_faillock is enabled, faillock --user alex lists failed sign-in attempts. Sudo activity appears in the system journal, commonly through journalctl _COMM=sudo, and traditional installations may also record it in /var/log/auth.log. Useful audit evidence includes the account, command, timestamp, and origin. A locked-out administrator needs a documented recovery credential and tested account-recovery process, not a shared emergency password.

Practical checks for shared and managed systems

An access review should be routine rather than a response to a crisis. Inventory human accounts, service identities, sudo membership, and shared credentials; remove people who have left; and set an end date for temporary access. Timestamps need care. Journal entries can be shown in local time, while journalctl --utc provides UTC; Brisbane remains on AEST while Sydney shifts to AEDT during daylight saving.

Backups and account separation protect each other. Personal files should not depend solely on an administrator’s home directory, and privileged credentials should not be stored in an ordinary user’s browser session. A recoverable administrator route, hardware-backed keys where supported, and encrypted offline recovery details reduce lockout risk. The exact method matters less than testing restoration and access before they are needed.

Clear access records also support Australian governance. Organisations covered by the Privacy Act 1988 need appropriate controls over personal information, while the Australian Signals Directorate’s Essential Eight highlights account management and logon auditing as security practices. A home desktop need not implement an enterprise framework, but the same principle holds: assign privileges deliberately, record their use, and revisit them as circumstances change. The practical takeaway is one account per person, narrowly assigned elevation, auditable changes, regular reviews, and a tested recovery path.