AI Agent Engineer

AI Agent Engineer

08 Permissions and Users

3 min read

08 Permissions and Users

Learning objectives

  • Inspect the current user identity and groups.
  • Understand file read, write, and execute permissions.
  • Use administrator privileges when required.

Command overview

CommandPurposeMeaningBasic usageExample
whoamiShow the effective userDisplays the effective user of the current processwhoamiwhoami
idShow user and group IDsDisplays UID, GID, and group membershipid [user_name]id
groupsShow groupsDisplays groups of the current or named usergroups [user_name]groups
chmodChange permissionsChange mode; changes read/write/execute permissionchmod permissions filechmod u+x -- script.sh
chownChange ownershipChange owner; usually needs authorization; see syntax reference belowchown user:group filechown -- USER:GROUP /absolute/path
sudoChange execution identity under policyRuns a command as root or another user under sudoers policysudo [options] commandsudo -l
suSwitch userSubstitute user; switches to another usersu user_namesu root
passwdChange a passwordSets a password for the current or named userpasswd [user_name]passwd

Common scenarios

Inspect the current identity:

whoami
id
groups

Give a script its owner execute permission:

chmod u+x -- run.sh
./run.sh

Set common file modes:

chmod 644 config.txt
chmod 755 script.sh

View sudo policy (authentication may be required):

sudo -l

Changing ownership changes external state, so this is syntax reference only:

sudo chown -- USER:GROUP /absolute/path

Notes for beginners

  • Linux modes commonly distinguish the file owner, group, and other users. ACLs, capabilities, and SELinux/AppArmor can add constraints.
  • r means read, w means write, and x means execute.
  • On a directory, x means traverse/search directory entries, not “execute the directory.” Reading directory names normally also requires r.
  • chmod u+x explicitly adds execute only for the owner. The result of chmod +x without a who can be affected by umask.
  • 644/755 are common examples, not universal security answers. Secret files, shared directories, and service accounts need an actual access-model design.
  • What sudo can run is determined by policy; it does not grant unlimited administrator authorization. Reconfirm before deletion, overwriting, or permission changes.
  • Do not operate as root long-term. When elevation is necessary, prefer sudo.

A minimal intuition for numeric modes

r=4, w=2, and x=1. Adding each group produces the owner/group/other digits. For example, 640 means owner read/write, group read-only, and no permission for others. Inspect rather than memorize:

umask
stat --format='%A %a %U:%G %n' -- config.txt
namei -l -- "$PWD/config.txt"

namei is part of util-linux and can be absent on a minimal system. It helps inspect directory traversal permission one component at a time.

Exercise without sudo

In your own lab directory, create run.sh and config.txt, then change only owner permissions:

chmod u+x,go-x -- run.sh
chmod u=rw,g=r,o= -- config.txt
stat --format='%A %a %U:%G %n' -- run.sh config.txt

Do not recurse with chmod or chown. A real recursive change must verify the canonical absolute path, that owner/group exist, symbolic links, mount boundaries, and authorization.

References

Backlinks