Linux is a multi-user operating system, so it needs a clear way to control who can read, modify, or execute files. Permissions protect configuration files, system binaries, scripts, secrets, and shared directories.
For DevOps engineers, permission mistakes are common sources of deployment failures and security issues.
Every file and directory has an owner and a group. Permissions are evaluated for three categories:
You can see this with ls -l.
ls -l deploy.sh
-rwxr-x--- 1 devops web 842 Jul 14 10:00 deploy.shIn this example:
devopswebrwxr-x---rwx NotationEach permission triplet contains up to three letters:
r = readw = writex = executeFor files:
For directories:
A permission string like rwxr-xr-- means:
Permissions are often represented with numbers:
r = 4w = 2x = 1Add them together for each category:
7 = rwx6 = rw-5 = r-x4 = r--So:
chmod 755 script.shmeans:
chmodchmod changes permissions.
Numeric form:
chmod 644 config.yaml
chmod 755 deploy.shSymbolic form:
chmod u+x deploy.sh
chmod g-w shared.txt
chmod o-r secret.txtExamples:
u+x adds execute for the ownerg-w removes write from the groupo-r removes read from othersTip: Scripts often need
chmod +x script.shbefore they can be run directly.
chown and chgrpUse chown to change owner and optionally group.
sudo chown devops deploy.sh
sudo chown devops:web /var/www/appUse chgrp to change only the group.
sudo chgrp web /var/www/appOwnership matters because even perfect permission bits will not help if the wrong user owns the file.
Linux also supports three special bits.
When setuid is set on an executable file, the program runs with the file ownerâs privileges.
chmod 4755 /path/to/programThis is powerful and should be used carefully.
On an executable file, setgid runs the program with the file groupâs privileges. On a directory, new files created inside inherit the directoryâs group.
chmod 2775 shared-dirThis is useful for team-shared directories.
The sticky bit on a directory means users can delete only files they own, even if the directory is otherwise writable.
chmod 1777 shared-tempA classic example is a shared temporary directory.
Note: The sticky bit improves safety in shared writeable directories by preventing users from deleting each otherâs files.
umaskumask controls the default permissions assigned to newly created files and directories.
umask
umask 022A common umask value is 022, which results in:
644755This means the owner can write, but group and others get read-only access by default.
You try:
./deploy.shbut get âPermission denied.â Check and fix:
ls -l deploy.sh
chmod +x deploy.shThe service runs as www-data, but the file is owned by another user and unreadable to the group. Fixing ownership or permission bits may solve the issue.
sudo chown root:www-data /etc/myapp/config.yaml
sudo chmod 640 /etc/myapp/config.yamlThat allows the owner and group to read while blocking everyone else.
Scenario: A service group needs read access to config.yaml, but everyone else should be blocked.
Question: Which permission mode from the lesson best matches that goal for a regular file?
<MCQExercise exercise={{
id: 'linux-permissions-q1',
title: 'Exercise 1: Choosing a restrictive file mode',
description: 'Pick the mode that gives the owner read and write, the group read, and others no access.',
options: [
{ id: 'a', text: '755' },
{ id: 'b', text: '640' },
{ id: 'c', text: '777' },
{ id: 'd', text: '600 for the directory only' },
],
correctId: 'b',
explanation: 'The tutorial uses 640 in a real-world config example because it maps to rw- for the owner, r-- for the group, and --- for others. That is a common pattern for service-readable configuration files.',
wrongExplanations: {
a: '755 makes the file world-readable and executable, which is far more open than the scenario requires.',
c: '777 gives everyone full access, which is usually unsafe for sensitive configuration.',
d: '600 is restrictive for a file owner, but the scenario specifically needs the group to read the file.',
},
}} />
Question: What is the benefit of setting the setgid bit on a shared directory such as a team project folder?
<MCQExercise exercise={{
id: 'linux-permissions-q2',
title: 'Exercise 2: Using setgid on directories',
description: 'Identify what setgid changes for new files created inside a shared directory.',
options: [
{ id: 'a', text: 'It forces every file to become owned by root.' },
{ id: 'b', text: 'It prevents anyone from entering the directory.' },
{ id: 'c', text: 'It makes all files executable by default.' },
{ id: 'd', text: 'It causes new files and directories inside to inherit the directory group.' },
],
correctId: 'd',
explanation: 'The lesson explains that setgid on a directory is useful for collaborative areas because new files inherit the directory group. That keeps team access consistent without manually fixing every new file.',
wrongExplanations: {
a: 'setgid affects group inheritance, not root ownership.',
b: 'Directory access still depends on the normal permission bits. setgid does not block entry.',
c: 'Execute permissions are controlled separately. setgid does not automatically make files executable.',
},
}} />
Question: If the umask is 022, what default file mode does the tutorial say you will usually see?
<MCQExercise exercise={{
id: 'linux-permissions-q3',
title: 'Exercise 3: Predicting umask results',
description: 'Choose the typical default permission for newly created files when umask is 022.',
options: [
{ id: 'a', text: '777' },
{ id: 'b', text: '755' },
{ id: 'c', text: '644' },
{ id: 'd', text: '400' },
],
correctId: 'c',
explanation: 'The tutorial states that a common umask of 022 typically results in files being created as 644 and directories as 755. That means only the owner gets write access by default.',
wrongExplanations: {
a: '777 would make new files fully writable and executable for everyone, which is not what umask 022 produces.',
b: '755 is the typical directory result mentioned in the lesson, not the usual default for plain files.',
d: '400 would be much more restrictive than the tutorial described and would not allow the owner to write the new file.',
},
}} />
x is the right to enter it, and r only lists names.chmod 755 for directories and executables, 644 for ordinary files covers almost everything.chmod u+x) and numeric mode for setting an exact state.chmod -R 777 is never the fix. It makes every file world-writable and hides the real problem.passwd works for unprivileged users, and a real risk elsewhere./tmp is what stops users deleting each other's files in a shared directory.chmod changes permissions. What the owner, group and everyone else are allowed to do. chown changes ownership, which user and group those permissions apply to. They solve different halves of the same problem, and picking the wrong one is a common source of frustration: if a service cannot write to its data directory, the fix is usually chown to the service's user rather than loosening the mode with chmod.
Because a directory is a list of names, not content. Read (r) lets you list what is inside; write (w) lets you create, rename and delete entries, which is why you can delete a file you cannot write to, as long as you can write to its directory. Execute (x) is the right to traverse the directory, to reach anything inside it. A directory with r but no x lets you see the file names and access none of them, which produces confusing "permission denied" errors on paths that clearly exist.
Effectively never. It makes a file readable, writable and executable by every account on the system, so any compromised process can rewrite it, and if it is a script something privileged runs, that is a direct path to privilege escalation. It is also usually treating the symptom: the real question is which user needs the access, answered with chown or by adding that user to the right group. The one defensible use is a deliberately shared scratch directory, and then it needs the sticky bit as well.
Three extra bits beyond rwx. setuid (chmod u+s) makes an executable run as its owner rather than the user invoking it. How /usr/bin/passwd can edit /etc/shadow on your behalf, and dangerous on anything else. setgid on a directory makes new files inherit the directory's group, which is the clean way to share a folder between team members. The sticky bit (chmod +t) on a world-writable directory restricts deletion to each file's owner, which is why /tmp is safe to share.
umask is a mask of bits to remove from the defaults when a file is created: 666 for files and 777 for directories. The common default of 022 therefore yields 644 for files and 755 for directories. Set a stricter 077 and new files are readable only by you, which suits a multi-user server. Check the current value with umask and set it in ~/.bashrc for a user or /etc/profile for everyone; note that it affects only newly created files, not existing ones.
Manage Linux accounts safely: useradd versus adduser, why usermod -aG needs a new login, the destructive -G mistake, sudo versus su and the account files.
Find, watch and stop Linux processes: use ps and top, send SIGTERM before SIGKILL, spot zombie states, read load average and find which process owns a port.
Manage Linux services with systemctl: start versus enable, daemon-reload after edits, writing a unit file, what Type= controls and reading logs.