On a single-admin server, permissions feel like a minor detail. Once a second person logs in, or a deployment tool starts writing files, they become the main thing standing between a tidy system and a confusing one. Most permission trouble on small teams comes from the same few habits: shared logins, broad sudo rights and files owned by whoever happened to create them. This guide walks through a simple model that scales from two people to a modest fleet.

Start With One Account Per Person

Every human who touches a server should have a personal account. Shared logins such as a single “admin” user make it impossible to tell who ran a command, and they make offboarding painful because you must rotate whatever credential everyone knew. Personal accounts also give your audit trail (shell history, last, authentication logs) real meaning.

Service software is the other half. Each daemon, whether a web application, a queue worker or a database, should run as its own dedicated system user with no interactive shell. If one service is compromised, the damage is limited to what that user can read and write.

Use Groups to Express Roles, Not People

Instead of granting access user by user, create groups that describe a job: a group for people who deploy the application, a group for those who read logs, a group for database operators. Then attach permissions to the group. When someone changes roles, you change their group membership rather than hunting through directories.

A useful habit is to name groups after the function, not the team that currently performs it. Names like deployers or logreaders stay accurate when staffing changes.

Keep sudo Narrow and Auditable

Full root access should be the exception. Prefer drop-in files in /etc/sudoers.d/ over editing the main sudoers file, and always edit with visudo so syntax errors are caught before they lock you out. Grant specific commands to specific groups where practical, for example allowing the deployers group to restart one service rather than run arbitrary commands as root.

Be cautious with commands that look harmless but can spawn a shell or write arbitrary files, such as text editors, pagers and some archive tools. Allowing them through sudo is effectively granting full root. When in doubt, test what a restricted account can actually do rather than trusting how the rule reads.

Understand the Basic Permission Model

Each file has an owner, a group and three sets of read, write and execute bits: for the owner, the group and everyone else. Directories use the execute bit to mean “can enter”. A few durable rules cover most situations:

• Application code should usually be owned by the deploy user and readable by the service user, but not writable by it.
• Writable data such as uploads or caches should live in a separate directory the service user owns.
• Secrets such as configuration files with database credentials should be readable only by the user that needs them.
• Avoid chmod 777 as a fix. If something works only with world-writable permissions, the real problem is ownership or group membership.

The setgid bit on a shared directory makes new files inherit the directory’s group, which keeps collaborative folders consistent. Access control lists (ACLs) are available when the classic owner/group/other model is too coarse, but use them sparingly because they are easy to forget about later.

A Quick Reference Table

Situation	Preferred approach	Common mistake
Several admins need server access	Personal accounts plus a shared admin group	One shared login
Deploy tool needs to restart a service	Narrow sudo rule for that command	Full passwordless root
Web app writes uploads	Dedicated data directory owned by the service user	Making the whole app directory writable
Team shares a working folder	Group ownership with setgid on the directory	World-writable permissions
Contractor needs temporary access	Time-boxed account, removed on completion	Reusing an existing employee login

A Hypothetical Example

Imagine a small team running one application server. Three developers log in with a single shared account, and the application runs as that same account. A contractor leaves, and nobody is sure whether their key is still authorized, so the team rotates the shared credential and breaks a deployment script in the process.

After a cleanup, each person has a personal account in a deployers group. The application runs as a dedicated appsvc user with no login shell. A single sudoers drop-in lets deployers restart the application service and nothing else. Uploads go to a directory owned by appsvc, while the code directory is owned by the deploy account and read-only to the service. The next time someone leaves, the team disables one account, removes one authorized key and nothing else changes.

Review Access on a Schedule

Permissions drift. Accounts for finished projects linger, and exceptions granted during an incident become permanent. Put a short review on the calendar, monthly or quarterly depending on team size, covering:

1. Accounts that have not logged in for a long time.
2. Members of privileged groups and sudo rules.
3. Authorized keys for each account.
4. World-writable files and unexpected setuid binaries.

Tools such as find, getent group and sudo -l -U username make these checks quick without any extra software. If you manage more than a handful of servers, configuration management or identity tooling helps keep accounts consistent, but the same principles apply.

Frequently Asked Questions

Should I ever log in directly as root? It is better avoided. Log in as a personal user and escalate with sudo for specific tasks so actions are attributed to a person. Many teams also disable direct root login over SSH.

What is the difference between a system user and a regular user? System users are intended for services. They typically have no password, no interactive shell and a lower numeric ID range, which signals that they are not meant for people.

How do I give someone read-only access to logs? Add them to a group that has read permission on the log directory, or use a group that your distribution already assigns to log files. Avoid granting full sudo just so someone can read logs.

Are ACLs better than groups? Not generally. Groups are simpler to reason about and audit. Use ACLs when a real requirement cannot be met by one owner and one group, and document where you used them.

How do I remove a departing team member safely? Disable or lock the account, remove their SSH keys, check for cron jobs and services running under their name, then reassign any files they own before deleting the account.

Next Step

Pick one server and run getent group and sudo -l for each administrator today. Write down who can do what, then remove any access nobody can justify. That single audit usually reveals the shared logins and overly broad rules worth fixing first.