Skip to main content
In this lesson we’ll cover Linux security basics focused on access control: user accounts, groups, file ownership and permissions, and privilege escalation. You’ll learn how to create and manage users, inspect account details, and switch identities safely using su and sudo. Each topic includes commands and examples so you can practice these essential administrative skills.
A presentation slide titled "Security and File Permissions" with the KodeKloud logo. It shows topic boxes like "Basic Security and Identifying File Types," "Creating Users and Groups," "Managing file permission and ownership," and highlighted lab items such as "Labs: Special Directories and Files."
Security in Linux spans many layers:
  • Authentication (who you are) — often handled via passwords, keys, and frameworks such as PAM (Pluggable Authentication Modules).
  • Access control (what you can do) — user and group permissions, file modes, ACLs, and mandatory access controls such as SELinux.
  • Network and service protection — firewalling (iptables, nftables, firewalld), SSH hardening, and service isolation.
  • Audit and accountability — centralized logs, sudo logs, and system accounting.
This lesson focuses on the basics: user and group accounts, how user metadata is stored, and how to escalate or switch privileges safely. For deeper reading:
A slide titled "Linux Accounts" showing a central "Linux Security" box connected to components like Access Controls, PAM, Network Security, SSH Hardening, SELinux, and "Many More." The slide is branded with the KodeKloud logo.

​
What is a user account?

A Linux user account represents an identity that can authenticate and perform actions on the system. Each account stores metadata used by the kernel and system services to control access. Typical account fields:
  • username
  • password placeholder (usually an x in /etc/passwd, with the hashed password in /etc/shadow)
  • UID (user ID) — unique integer
  • primary GID (group ID)
  • optional comment / GECOS (human-readable info)
  • home directory
  • default login shell
Account and group data are stored in:
  • /etc/passwd — account metadata and login shell/home
  • /etc/shadow — encrypted password hashes (restricted)
  • /etc/group — groups and group members
Example: two developers (bob and michael) can be members of the same group (e.g., developers) to share access to common files. Example contents of /etc/passwd and /etc/group: 
$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
bob:x:1000:1000:Bob Kingsley,,,:/home/bob:/bin/bash
michael:x:1001:1001::/home/michael:/bin/sh

$ cat /etc/group
ssh:x:118:
lpadmin:x:119:
scanner:x:120:saned
avahi:x:121:
saned:x:122:
colord:x:123:
geoclue:x:124:
pulse:x:125:
pulse-access:x:126:
gdm:x:127:
systemd-coredump:x:999:
bob:x:1000:
developers:x:1003:bob,michael

​
Account field breakdown (quick reference)

FieldDescriptionExample
UIDUnique numeric user identifier. 0 is root.1001
GIDPrimary numeric group identifier for the user.1001
UsernameHuman-readable account name used to log in.michael
Home directoryDefault directory after login./home/michael
Login shellDefault shell executed at login./bin/bash
GECOSOptional comment: user’s full name, contact info, etc.Bob Kingsley
Inspect a user’s IDs and groups: 
$ id michael
uid=1001(michael) gid=1001(michael) groups=1001(michael),1003(developers)
Check a user’s home and shell by reading /etc/passwd (see example above).

​
Account types

  • User account — for a person who needs access.
  • Superuser (root) — UID 0; unrestricted privileges.
  • System accounts — created for OS services; often have low UIDs and no interactive shell.
  • Service accounts — created for specific applications (e.g., nginx, mysql).
A presentation slide titled "Account Types" showing four colored boxes for User Account, Superuser Account (UID = 0), System Accounts (with UID ranges), and Service Accounts, plus example usernames (e.g., Bob, root, ssh, nginx). The slide includes the KodeKloud logo and illustrative icons.
CommandPurposeExample
idShow UID, GID, and supplementary groups for a user.id michael
whoList users currently logged in.who
lastShow login/logout history and reboots.last
Examples: 
$ id
uid=1000(michael) gid=1000(michael) groups=1000(michael)

$ who
bob      pts/2        Apr 28 06:48   (172.16.238.187)

$ last
michael  :1   :1        Tue May 12 20:00  still logged in
sarah    :1   :1        Tue May 12 12:00  still running
reboot   system boot 5.3.0-758-gen  Mon May 11 13:00 - 19:00 (06:00)

​
Switching users: su vs sudo

There are multiple ways to run commands as another user. Choose the method that fits your operational and auditing requirements.

​
su (substitute user)

  • su starts a shell as another user and typically requires the target user’s password.
  • su - opens a login shell, loading the target user’s environment.
  • Useful for interactive sessions, but less auditable because commands aren’t centrally logged by sudo.
Examples: 
$ su -
Password:
root@host:~#

$ su -c "whoami"
Password:
root

​
sudo (delegate privileges)

  • sudo lets authorized users run commands as another user (commonly root) by authenticating with their own password.
  • Sudo policies are configured in /etc/sudoers and in files under /etc/sudoers.d/.
  • sudo provides better auditing and fine-grained privilege delegation.
Example usage: 
michael@ubuntu-server:~$ sudo apt-get install nginx
[sudo] password for michael:
Sample /etc/sudoers (simplified): 
# /etc/sudoers - example entries
User privilege specification
root    ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
# Allow bob to run any command
bob     ALL=(ALL:ALL) ALL
# Allow sarah to reboot the system
sarah   localhost=/usr/bin/shutdown -r now
# See sudoers(5) for more information on "#include" directives: https://man7.org/linux/man-pages/man5/sudoers.5.html
#includedir /etc/sudoers.d
Always use visudo to edit /etc/sudoers. visudo locks the file and checks for syntax errors before saving, preventing misconfiguration that could lock out administrative access.
Sudo examples of delegation:
  • Grant full root access to a user: username ALL=(ALL:ALL) ALL
  • Grant a group limited privileges: %developers ALL=(ALL) /usr/bin/systemctl restart myservice

​
Best practice: avoid direct root logins

  • Disable direct root SSH access (set PermitRootLogin no in /etc/ssh/sshd_config).
  • Encourage administrators to use sudo for privilege escalation. This enables accountability, because sudo logs which user ran which command.

​
Summary and next steps

  • User and group accounts are the foundation of Linux access control. Their metadata lives in /etc/passwd and /etc/group.
  • Use id, who, and last to inspect accounts and sessions.
  • Prefer sudo over su for privilege escalation because sudo is auditable and configurable.
  • Edit sudoers only with visudo to avoid syntax errors.
  • Practice creating users, placing them in groups, and configuring sudo policies in a lab environment.
Further references: Practice exercises (suggested):
  • Create two users, add them to a shared group, and verify file permissions for group members.
  • Configure a sudo rule that allows a non-root user to run a single administrative command.
  • Disable direct root SSH access and confirm you can still perform administrative tasks using sudo.

Watch Video