Users, Permissions, and Sudo

Linux permissions decide who can read, write, and execute files. Production apps should usually run as a dedicated user, not as root.

sudo adduser deploy
sudo usermod -aG sudo deploy
ls -l app.log
sudo chown deploy:deploy app.log
chmod 640 app.log

Permission bits are owner, group, and others:

-rw-r-----  deploy deploy  app.log

Further Learning

• “Linux file permissions chmod chown” — permission model
• “sudoers Linux” — privilege escalation
• “run service as non-root Linux” — safer app runtime

Users, Permissions, and Sudo

On Linux, root is the all-powerful super-user account. Running your app as root is risky — if something goes wrong (a bug, an attack), it has full access to everything. Best practice: create a normal user for your app to run as.

Making a safer user

sudo adduser deploy          # create a new user called "deploy"
sudo usermod -aG sudo deploy  # let them run sudo when needed

Now your app runs as deploy, with only the access deploy actually needs — not full system control.

Who can touch a file

Every file has an owner, a group, and permission bits for each:

ls -l app.log
-rw-r-----  deploy deploy  app.log

That reads: the owner (deploy) can read/write, the group can only read, and everyone else gets nothing.

sudo chown deploy:deploy app.log   # change who owns it
chmod 640 app.log                  # set who can read/write

The command to avoid

In one sentence

Run your app as a dedicated non-root user (not root), understand a file’s owner/group/permissions before changing them with chown/chmod, and never reach for chmod 777 as a shortcut.

Want to go deeper?

Switch to Expert mode above for the full permission-bit breakdown and sudoers configuration.