Why chmod 777 Won't Save You — Linux Permissions, SUID, SGID & ACLs | Zero to LLMOps (Day 4)

Day 4 of a free 180-day DevOps course. Yesterday we answered "who are you" - users, groups, passwd, shadow, sudoers. Today we answer the other half of the same question: now that the system knows who you are, what exactly are you allowed to do to a file, and who decided that? This is the day where chmod 777 stops being the thing you type when something does not work, and starts being the thing you never type again. • rwx and octal, until you can convert either direction in your head - r=4, w=2, x=1, summed per class, so rwxr-xr-- is 754 • The directory trap almost everyone gets wrong: on a directory x means "can enter", r means "can list", and w means "can create and delete inside". Read on a directory without execute is nearly useless, and we show why • umask, which is subtractive, not additive - the mask is taken away from 666 for files and 777 for directories, which is why the default 022 gives you 644 files and 755 directories • SUID (4000) - why /usr/bin/passwd has to run as its owner rather than as you, because it needs to write root-owned /etc/shadow on your behalf. The cleanest real example of privilege escalation that is meant to happen • SGID (2000) on a directory - new files inherit the directory's group instead of the creator's. If you have ever fought a shared team folder, this is the fix • The sticky bit (1000) - why /tmp is world-writable and yet nobody can delete your files out of it • ACLs, for the moment plain rwx runs out - one owner and one group is not always enough. getfacl, setfacl -m, setfacl -x, and the little + in ls -l that tells you an ACL is hiding there • chattr +i, the immutable flag that stops even root from editing a file until it is unset Project step: we lock down /opt/fresher_project properly - 750, owned by svc_fresher:devops-trainees, SGID on the logs directory so new logs inherit the group, an ACL so I keep read access without joining the group, and umask 027 added to boot_logger.sh so every log it writes lands as 640 instead of world-readable 644. ⏱ Chapters 00:00 Intro: nine bits, three special bits, and ACLs 01:14 Recall: passwd fields, svc_fresher, the -G trap, su vs sudo 03:04 The three classes: owner, group, other 03:54 What rwx means on a file vs a directory 05:25 Octal: r=4, w=2, x=1, so rwxr-xr-- is 754 06:40 chmod: numeric vs symbolic 08:02 Why root ignores the permission bits 09:23 umask is subtractive: 666 files, 777 directories 10:38 Choosing a umask: 022 vs 027 13:19 SUID: running as the file's owner, not the caller 14:36 Spotting SUID: rws in the owner slot 15:57 SGID on a file 17:18 SGID on a directory: group inheritance 18:42 The sticky bit: 1777, +t, and why /tmp is safe 20:03 ACLs: permissions for extra named users 24:04 Lab: octal drills with chmod 24:51 Lab: directory permissions and traversal 26:43 Lab: umask in practice 27:37 Lab: SGID on a shared directory 29:20 Lab: sticky bit, deleting someone else's file 30:40 Lab: setfacl -m to grant access 31:56 Lab: setfacl -x to revoke 33:13 Project: SGID on the logs directory 34:31 Project: confirming group inheritance 35:46 Recap: the nine bits and the special bits 37:07 Definition of done and homework Homework: convert rwxr-x--- to octal and 640 back to symbolic, from memory. Explain what SGID does on a directory and why the logs folder wants it. Then confirm /opt/fresher_project is 750, owned by svc_fresher:devops-trainees, and that boot_logger.sh still runs clean as svc_fresher and writes 640 logs. 📚 FREE COURSE MATERIAL - every lesson, lab and answer key https://github.com/mahadikabhijeet/ze... All 185 written lessons, the labs, the answer keys and two self-paced study guides are on GitHub, free and open. You do not need the videos to follow the course. ◀ Previous — Day 3: Users, Groups, /etc/passwd and Shadow, su vs sudo and sudoers · ▶ Next — Day 5: Text Processing I, grep and regex fundamentals 🔔 Subscribe for the full path from zero to LLMOps.