Kali Linux Users, Permissions, and sudo

Almost every “it works on my machine but fails on the server” moment traces back to a permission or ownership mismatch. Kali Linux is a Debian-based system, so the user and permission model you learn here is the same one running your cloud VMs, CI runners, and containers. Getting comfortable with users, groups, ownership, and sudo is one of the highest-leverage Linux skills a DevOps engineer can build.

The Linux User Model

Linux is multi-user by design. Every process runs as some user, and every file is owned by a user and a group. The kernel makes access decisions by comparing the user running a process against the ownership and permission bits on the file it wants to touch.

Three kinds of accounts matter:

Account type	Who it is	Example
root (superuser)	The all-powerful administrative account, UID 0. Bypasses permission checks.	root
Regular user	A human login with a home directory and limited rights.	kali, james
System / service account	Non-login accounts that own daemons and files.	www-data, postgres, sshd

Every user has a numeric UID (user ID) and belongs to one or more groups, each with a numeric GID (group ID). Names like kali and www-data are just human-friendly labels; the kernel works with the numbers.

# Who am I, and what UID/GID/groups do I have?
id

# Just the username of the current user
whoami

Typical output of id:

uid=1000(kali) gid=1000(kali) groups=1000(kali),27(sudo),100(users)

That tells you the user kali is UID 1000, has a primary group kali (GID 1000), and is a member of the sudo group — which, as you’ll see, is what grants administrative rights.

💡 Note — Users live in /etc/passwd and groups in /etc/group. These are plain text files. cat /etc/passwd is a safe, read-only way to see every account on the system, including service accounts you never log in as.

Users and groups on disk

# List all local user accounts (one per line, name only)
cut -d: -f1 /etc/passwd

# Show which groups a user belongs to
groups kali

# See the groups a service account like www-data is in
id www-data

Understanding groups matters because permissions are frequently granted to a group rather than an individual — for example, adding a deploy user to a docker or www-data group so it can manage containers or write to a web root.

root and sudo

The root account (UID 0) can read, write, and execute anything, ignore permission bits, and stop or start any service. That power is exactly why you avoid logging in and working as root all day: a typo, a bad script, or a compromised process running as root can damage the whole system.

The modern approach is sudo — “superuser do.” Instead of becoming root, a permitted regular user runs a single command with elevated rights and is logged doing it.

# Run one command as root
sudo apt update

# Read a root-only file
sudo cat /etc/shadow

# Start an interactive root shell (use sparingly)
sudo -i

Who is allowed to use sudo is controlled by the /etc/sudoers file and, on Debian/Kali, by membership in the sudo group. Add a user to that group and they gain administrative rights:

# Add user 'deploy' to the sudo group (requires existing sudo rights)
sudo usermod -aG sudo deploy

🔐 Security Note — Least privilege means each account gets only the rights it needs and no more. Run as a regular user by default and reach for sudo only for the specific command that needs it. Never hand out blanket sudo access or, worse, run services as root “to avoid permission errors” — a permission error is the system telling you the boundary is working. Fix the ownership, don’t remove the boundary.

Modern Kali does not run the desktop as root

Older releases of Kali Linux (before 2020.1) shipped with a single root account and logged you straight into the desktop as root. That reflected Kali’s origins as a specialist security-testing distribution used in short-lived, disposable sessions.

Modern Kali changed this to match standard Linux practice: the default account is a regular, non-root user (traditionally named kali) that belongs to the sudo group. You do everyday work — browsing, editing, running tools — as that unprivileged user and elevate with sudo only when a task genuinely requires root.

	Older Kali (pre-2020.1)	Modern Kali (2020.1+)
Default login	root	Regular user (kali)
Desktop runs as	root	Unprivileged user
Admin actions	Already root	sudo <command>
Alignment with Ubuntu/Debian norms	No	Yes

This is a strictly better default: fewer accidents, a clearer audit trail, and habits that transfer directly to the Ubuntu and Debian servers you’ll manage in production.

🛠️ DevOps Perspective — Production servers, container images, and CI runners follow the same rule: no interactive root logins. You SSH in as a named user and use sudo for privileged steps, which leaves an auditable record of who did what. Learning Kali the modern way builds exactly the muscle memory your production Linux hosts expect.

File Ownership and Permission Bits

Every file and directory has an owner (a user), a group, and a set of permission bits. ls -l shows all three:

ls -l script.sh

-rwxr-xr--  1  kali  developers  482  Aug 12 09:30  script.sh
│└┬┘└┬┘└┬┘     │     │
│ │  │  │      │     └─ group owner: developers
│ │  │  │      └─ user owner: kali
│ │  │  └─ other: r--  (read only)
│ │  └─ group: r-x  (read + execute)
│ └─ owner: rwx  (read + write + execute)
└─ file type: - = regular file, d = directory, l = symlink

Permissions come in three classes — owner (user), group, and other (everyone else) — and each class gets three bits:

Bit	Symbol	On a file	On a directory
Read	r	View contents	List entries
Write	w	Modify contents	Create/delete entries inside
Execute	x	Run it as a program	Enter/traverse (cd) into it

So -rwxr-xr-- reads as: owner can read/write/execute, group can read/execute, everyone else can only read.

Numeric (octal) notation

Each permission has a numeric value: read = 4, write = 2, execute = 1. Add them per class to get a single digit, then write one digit for owner, group, and other:

Symbolic	Calculation	Octal
rwx	4+2+1	7
rw-	4+2	6
r-x	4+1	5
r--	4	4
---	0	0

So -rwxr-xr-- = 754. Common values you’ll use constantly:

• 644 (rw-r--r--) — normal files: owner edits, everyone reads.
• 755 (rwxr-xr-x) — scripts and directories: owner full, others read/run.
• 600 (rw-------) — private files like SSH keys: owner only.
• 700 (rwx------) — private directories: owner only.

Changing Permissions: chmod

chmod (“change mode”) sets permission bits. It accepts both symbolic and numeric forms.

# Numeric: set exactly to rwxr-xr-x
chmod 755 script.sh

# Symbolic: add execute for the owner only
chmod u+x script.sh

# Symbolic: remove read/write from "other"
chmod o-rw notes.txt

# Symbolic: give the group read+write, leave the rest untouched
chmod g+rw shared.log

# Recurse into a directory tree (use with care)
chmod -R 750 /opt/app

The symbolic form is built from a class (u=user/owner, g=group, o=other, a=all), an operator (+ add, - remove, = set exactly), and the bits (r, w, x). Numeric form sets all bits at once and is the clearest way to declare an exact end state.

⛔ Production Warning — Never run chmod -R 777 on application or web directories to “make it work.” 777 grants everyone full read/write/execute and is a serious security hole — any user or compromised process can overwrite your code. Find the correct owner/group instead (see chown below). Only test and modify systems you own or are explicitly authorized to manage.

Changing Ownership: chown

chown (“change owner”) sets the user and/or group that owns a file. Changing ownership requires root, so you’ll typically prefix it with sudo.

# Change the owner to 'deploy'
sudo chown deploy script.sh

# Change owner AND group at once (user:group)
sudo chown deploy:developers script.sh

# Change only the group (leading colon)
sudo chown :www-data /var/www/site/index.html

# Recursively give a web root to the web-server account
sudo chown -R www-data:www-data /var/www/site

The user:group syntax is the one to memorize — it’s how you hand a directory to a service account like www-data (Apache/Nginx) or postgres in one command.

🔎 Troubleshooting Tip — “Permission denied” almost always has one of two causes: (1) the file’s permission bits don’t allow your class the action you want, or (2) the file is owned by a different user/group than the process trying to use it. Diagnose with ls -l <file> and id. Compare the owner/group on the file against your uid/gid. Fix the smaller of the two — adjust bits with chmod or ownership with chown — rather than escalating everything to root.

Try It: Create, Inspect, and Adjust

Work through this on your Kali machine. Everything happens inside your own home directory, so it’s completely safe.

🧪 Try It — Practice the full ownership-and-permissions loop:

# 1. Create a working directory and a file
mkdir ~/perms-lab && cd ~/perms-lab
echo '#!/bin/bash' > deploy.sh
echo 'echo "hello from deploy"' >> deploy.sh

# 2. Inspect the default permissions and ownership
ls -l deploy.sh
#   Note the owner, group, and bits (likely -rw-r--r--, i.e. 644)

# 3. Try to run it — it fails because there's no execute bit
./deploy.sh          # bash: ./deploy.sh: Permission denied

# 4. Add execute for the owner and confirm the change
chmod u+x deploy.sh
ls -l deploy.sh      # now -rwxr--r--
./deploy.sh          # prints: hello from deploy

# 5. Set an exact numeric mode and read it back
chmod 750 deploy.sh
ls -l deploy.sh      # -rwxr-x--- : owner full, group read/exec, other nothing

# 6. Inspect your own identity
id                   # your uid, gid, and group memberships

# 7. Change the group owner (needs sudo) and verify
sudo chown :sudo deploy.sh
ls -l deploy.sh      # group is now 'sudo'

# 8. Clean up
cd ~ && rm -rf ~/perms-lab

By the end you’ve created a file, watched a missing execute bit block it, fixed it symbolically and numerically, and changed group ownership with sudo — the exact sequence you’ll repeat on real servers.

Why This Matters in Real Operations

Permissions and ownership are not academic — they’re the root cause of a large share of everyday DevOps incidents:

• Deploy keys and SSH keys must be 600 (owner read/write only). SSH refuses to use a private key that is group- or world-readable and prints Permissions are too open — a deliberate safety check. See the SSH lesson for the full workflow.
• Service accounts like www-data, nginx, or postgres own their data and runtime directories. If your web root is owned by your login user instead of the web server, the server gets “permission denied” and returns 500s.
• Config and secrets files should be tightly scoped (640 or 600) so unprivileged processes can’t read credentials.
• CI/CD runners frequently fail because a checked-out script has no execute bit, or an artifact is owned by root and the pipeline user can’t clean it up.

🛠️ DevOps Perspective — When a deployment “mysteriously” fails, ls -l and id are your first two commands, not your last. A misconfigured owner or a chmod 777 shortcut is both a functional bug and a security finding. Treat correct ownership and least-privilege permissions as part of the deliverable, the same way you’d treat passing tests.

Where to Go Next

• Put these skills to work over the network in Networking Fundamentals, then use them to lock down remote access in the SSH lesson.
• For deeper, ongoing Linux administration topics — user management, filesystems, and system hardening — browse the Linux Admins content.

What You Learned

• Linux is multi-user: every process and file has a user and group owner identified by numeric UID/GID, and the kernel enforces access based on them.
• root (UID 0) bypasses all checks, so you work as a regular user and elevate with sudo for individual commands — driven by membership in the sudo group.
• Modern Kali logs you in as an unprivileged user and no longer runs the desktop as root, unlike older releases — matching standard Debian/Ubuntu practice and building production-ready habits.
• Permission bits are read (4), write (2), execute (1) across three classes — owner, group, other — expressed symbolically (rwxr-xr--) or numerically (754).
• chmod changes permission bits (symbolic u+x or numeric 755) and chown changes user:group ownership; together they resolve the “Permission denied” errors behind deploy keys, service accounts, and CI failures.
• Least privilege — the smallest rights needed, never chmod 777 or blanket root — is both a security control and an operational best practice.