Users, groups, and sudo

Linux uses users and groups to decide which files and operations a process may access. Separate accounts reduce the damage caused by a mistake or compromised service.

Do not work as root all day. Use a regular account and elevate only the command that needs administrative access.

Create a regular user

sudo adduser ada

adduser creates the account, home directory, and initial group. Confirm the result:

id ada
getent passwd ada

If this person needs administrative access, add the account to Ubuntu’s sudo group:

sudo usermod -aG sudo ada

The -a matters. It appends a supplementary group. Omitting it can replace the user’s existing supplementary group list.

New group membership normally appears after the user starts a new login session. Test it in a second session before changing the account you currently depend on.

Use groups for shared access

Suppose two deployers need access to /srv/notes. Create a dedicated group instead of making the directory world-writable:

sudo groupadd notes-deploy
sudo usermod -aG notes-deploy ada
sudo chgrp -R notes-deploy /srv/notes

Then choose directory permissions that match the workflow. Do not apply recursive permission changes until you have inspected the tree and understand which files should be executable.

sudo is a boundary

sudo runs one command with elevated privileges and records the attempt. Read the complete command, resolved path, and target before pressing Return.

Redirection is a common trap:

sudo echo enabled > /etc/notes.conf

The shell opens the file before sudo runs, so this usually fails for a regular user. Use a privileged editor or sudo tee when appropriate, and review the value before writing it.

Try this: on a disposable system, create a user without sudo access. Verify its identity, then explain which exact additional permission you would grant for one administrative job.