Linux Permissions Explained: rwx, SUID, SGID, Sticky

🤷 A web server suddenly started receiving an unusually high number of requests. The task sounded simple: 👉 Find which IP address was hitting the server the most from the access logs. At first glance, it felt like just another Linux command exercise. But while solving it, I realized troubleshooting is less about memorizing commands and more about thinking step by step. The log file contained thousands of requests, with IP addresses in the first column. So I started breaking the problem down: First, extract only the IP addresses: awk '{print $1}' access.log Then I remembered something important: uniq -c only counts adjacent duplicate lines. That meant I couldn’t directly count repeated IPs unless identical IPs were grouped together first. So the next step became: awk '{print $1}' access.log | sort Now duplicate IPs were arranged together. After that: awk '{print $1}' access.log | sort | uniq -c This gave the count of requests from each IP. Then I sorted the counts numerically: awk '{print $1}' access.log | sort | uniq -c | sort -n And finally: awk '{print $1}' access.log | sort | uniq -c | sort -n | tail -n 1 The last line revealed the IP address generating the highest number of requests. The more I learn Linux and Shell Scripting, the more I enjoy the debugging mindset behind it. Would genuinely love any feedback. #Linux #DevOps #ShellScripting #Troubleshooting #Cloud #Docker #Kubernetes #LearningInPublic

A couple of months ago my feed was flooded with do you know Linux, and then some explanations of cd, ls and pwd to "prove" that the author does. Let's skip that stuff. We then moved on to some ancient newbie trolling of the form go type "rm -rf / --no....". Obviously, no, don't type it, it removes all your files, or it might, it might get stuck and die in /proc or /sys or some virtual filesystem first if you're very lucky and crash. That'd be preferable, but probably no, time to find the backups. This week I've seen a fair few of these fork bombs posted, but no descriptions of what it does: :(){ :|:& } Normally there'll be a ;: at the end of it, but I'll leave that out. It's not at all Linux specific, it's shell script, it will work in a lot of different shells, many will be using bash. Firstly let's rewrite it, less obfuscated, you could sed s/:/new_func/g new_func() { new_func | new_func & } Do you get it now? It's a function, called new_func, that calls new_func, pipes the result to new_func, and runs it in the background, each new_func is doing exactly the same, so, it'll recurse infinitely, creating as many new_func processes as it can each time. It might crash things, break, die, in any number of ways, you could have set your box up to limit the number of user processes, perhaps you didn't even let users log in, that's often the safest bet! Anyway, I've seen it too many times, many of us have seen it years ago before Linux was even created. It's not new, and it's not very clever. Don't run it, but do try to understand these things yourself, yeah, wikipedia has a good page on it, but they rewrite the function calling it fork() which is a distraction, because it's not really fork, it's multiple forks, 2 in each hand, where each is 4, 8, 16... forks. It's a multi-pronged attack on your own box. You don't need AI to explain it, but you should be able to understand code like this, that others give you, or that AI gives you, and that skill is far more important than being able to share these silly 1st year computer science pranks. People really need to read the code, and understand the code before running it on a production system. And the way these things are being shared, it seems that maybe they do not. Keep learning, keep sharing, but let's move past beginner pranks as proof of being a "Linux expert", as I said, it's not even Linux specific. If we start soon getting posts about how to snapshot a filesystem, how to take reliable backups and test them regularly and how to run safe unix type systems, I'll be very happy, it'll be a nice change from a reminder of the worst bits of 1st year undergrad days when the box you needed was trashed by one user most afternoons.

I just started something I've been putting off for too long. Day 1 of my Linux SysAdmin journey — documented publicly. Every single day. No skipping. No shortcuts. ━━━━━━━━━━━━━━━━━━ Here's what Day 1 actually looked like: ━━━━━━━━━━━━━━━━━━ Most people learn Linux by memorizing commands. I'm learning it by understanding WHY each piece exists. Today: The Linux Filesystem Hierarchy. Not a boring list of directories. But the REASON behind each one: 📁 /etc  → The brain. Every service reads config from here. 📁 /var  → The memory. Logs, mail queues, database files. 📁 /proc → The live pulse. Not a real disk — it's the kernel talking. 📁 /boot → The spine. If this fills up, your server won't reboot. 📁 /tmp  → The whiteboard. Cleared on every reboot. Don't store things here. Then I built something practical: A server audit script that baselines any Linux machine in 10 seconds. What it checks: → Disk AND inode usage (most people only check disk) → Open ports — what's actually exposed → Failed SSH login attempts → Config files changed in the last 24 hours ━━━━━━━━━━━━━━━━━━ The lesson that hit hardest: ━━━━━━━━━━━━━━━━━━ Your disk can show 70% free. Your server can still refuse to create new files. Because inodes — the filesystem's index — filled up. Check with: df -i This is the kind of thing that only shows up in production at the worst possible time. ━━━━━━━━━━━━━━━━━━ If you're on a similar path — let's connect. Drop a comment: what's the one Linux concept that took you the longest to actually understand? Scripts + README on GitHub → link in comments. See you on Day 2. 🐧 ───────────────────────────── #Linux #SysAdmin #DevOps #LearningInPublic #BashScripting #Ubuntu #OpenSource #TechCommunity #LinuxJourney #CareerDevelopment

Reproducible builds expose inconsistencies between source code and compiled binaries in Debian packages. This creates a mechanism to detect software supply chain tampering at build time. The article highlights that reproducibility ensures “the same source code always produces the same binary output.” Any deviation signals environmental influence, injected code, or build-time manipulation. This is particularly relevant where build environments include: - timestamps - file ordering - compiler variations In real systems, many binaries are built in centralized pipelines or by upstream maintainers. If those environments are compromised, the resulting packages can differ from expected outputs without obvious signs. This affects: - package managers like APT - internal build systems - container image layers derived from Debian Most teams never compare rebuilt packages against upstream binaries. From a system hardening perspective, this is worth reviewing. In practical terms, it is a good time to review: - Build environment consistency in CI/CD pipelines - Deterministic build configurations for internal packages - Use of reproducibility testing tools - Controls around compiler and dependency versions Article: https://lnkd.in/eqaZ2KYu #DevSecOps #Linux #InfrastructureSecurity

Hi! Why Copy on Write Optimizes Memory in Modern Kernels > TL;DR — Copy‑on‑write (CoW) lets the kernel share physical pages between parent and child after a `fork()`, postponing actual copies until a write occurs. This strategy slashes memory consumption, accelerates process creation, and improves cache and TLB behavior on modern systems. Process creation is the most frequent operation in a multitasking operating system. Every time a user launches a program, the kernel must allocate a new address space, copy the executable image, and set up bookkeeping structures. Historically, this was an expensive, memory‑hungry step. Modern kernels—Linux, BSD, macOS—have converged on a single powerful technique: copy‑on‑write. By deferring copies until they are truly needed, CoW turns a potentially linear‑time, memory‑intensive operation into a near‑constant‑time, memory‑light one. The following sections unpack the mechanics, the performance wins, and the practical limits of CoW in today’s kernels. Before CoW, the classic `fork()` implementation performed a deep copy of the parent’s entire address space. On a system with 8 GiB of RAM, for example, a naïve fork could temporarily require an additional 8 GiB of physical memory just to duplicate page tables and data. Early Unix variants mitigated this with swap and overcommit, but the cost remained prohibitive for high‑frequency process spawning (e.g., web servers handling thousands of requests per second). Read the full guide: https://lnkd.in/dWwx7SRA #copyonwrite #memorymanagement #kernel #performance #operatingsystems

Hi! Why Copy on Write Optimizes Memory in Modern Kernels > TL;DR — Copy‑on‑write (CoW) lets the kernel share physical pages between parent and child after a `fork()`, postponing actual copies until a write occurs. This strategy slashes memory consumption, accelerates process creation, and improves cache and TLB behavior on modern systems. Process creation is the most frequent operation in a multitasking operating system. Every time a user launches a program, the kernel must allocate a new address space, copy the executable image, and set up bookkeeping structures. Historically, this was an expensive, memory‑hungry step. Modern kernels—Linux, BSD, macOS—have converged on a single powerful technique: copy‑on‑write. By deferring copies until they are truly needed, CoW turns a potentially linear‑time, memory‑intensive operation into a near‑constant‑time, memory‑light one. The following sections unpack the mechanics, the performance wins, and the practical limits of CoW in today’s kernels. Before CoW, the classic `fork()` implementation performed a deep copy of the parent’s entire address space. On a system with 8 GiB of RAM, for example, a naïve fork could temporarily require an additional 8 GiB of physical memory just to duplicate page tables and data. Early Unix variants mitigated this with swap and overcommit, but the cost remained prohibitive for high‑frequency process spawning (e.g., web servers handling thousands of requests per second). Read the full guide: https://lnkd.in/dWwx7SRA #copyonwrite #memorymanagement #kernel #performance #operatingsystems

The Linux kernel is beginning to integrate Rust components to mitigate long-standing memory safety issues. This shift reflects a deeper effort to reduce systemic risk in core infrastructure. According to the article, Rust’s guarantees around memory safety help prevent bugs before code is even executed. This is particularly important in kernel development, where even minor errors can lead to system-wide compromise. The integration is incremental, focusing on new components rather than rewriting existing code. For operators, this means a gradual change in how kernel code is built and maintained. Over time, systems may include a mix of C and Rust components, which can affect debugging, tooling, and compatibility. Teams may also need to adapt to new build dependencies and workflows. Mixed-language environments often introduce new operational complexity before benefits are fully realized. For Linux administrators and infrastructure teams, this has practical implications. In practical terms, it is a good time to review: - Kernel build and deployment pipelines - Compatibility of tooling with Rust-based components - Training needs for teams maintaining kernel-level code - Testing processes for new kernel releases Article: https://lnkd.in/eRGmt6zD #LinuxKernel #DevOps #Infrastructure #OpenSource #SecurityEngineering

Your server is running out of memory. Linux has to make a decision. It picks one of your processes and kills it. Not the one using the most memory. Not the one that started last. The one it scores highest on a secret algorithm. Your database just got murdered. . . The Linux OOM Killer — the most misunderstood survival mechanism in any operating system. When RAM fills up completely, the kernel can't allocate memory for anything. Processes start failing. The kernel panics. The system becomes unusable. So Linux does something brutal but necessary — it picks one process to kill, frees its memory, and keeps the system alive. The algorithm works like this. Every process gets an OOM score from 0 to 1000. Higher score = more likely to die. The score is calculated based on: how much memory the process is using (as a percentage of total RAM), how long it's been running (longer = slightly protected), whether it's a root process (slightly protected), and whether the process has set its own oom_score_adj value (-1000 to +1000). The killer picks the highest scorer and sends it SIGKILL. No warning. No SIGTERM. No cleanup. Just gone. Most engineers miss this: You can protect critical processes yourself. Set oom_score_adj to -1000 on your database process and the OOM Killer will never touch it. Set it to +1000 on a disposable worker and it dies first, every time. Most engineers running databases in production have never set this. Their database is as vulnerable as every other process. → Check any process's OOM score: cat /proc/<pid>/oom_score → Protect critical processes: echo -1000 > /proc/<pid>/oom_score_adj → dmesg | grep -i "oom" shows you if OOM Killer has already fired — check this on every prod server Linux won't ask you which process matters most. Tell it in advance. Have you ever found OOM Killer entries in your dmesg logs? 👇 #Linux #SoftwareEngineering #DevOps #SRE #BackendDevelopment #SystemsProgramming #HLD

What can I do? I think eBPF is the future of infra, and Jalki, is a try on making it more accessible, it’s going to have a serious re-design very soon !!

I Released a free Windows diagnostic tool today: ETDucky.ProcDelta. 1. On a working machine, hit Record, perform the action a user can't, hit Stop, save baseline. 2. On the broken machine, load the baseline, perform the same action, hit "Run Diff". 3. Get a ranked list of every environmental difference: registry keys that resolved here but not there, files with mismatched ACLs, network hosts that connected on one but not the other, .NET exceptions that fired only on the failing run. Kernel-level capture via ETW. Per-PID filtered (handles service tree spawns). Registry value content captured as SHA-256 to detect drift without storing the bytes. Self-contained .exe, ~58 MB, Administrator required. Open source under Apache 2.0. Free for anyone to use. Download: https://lnkd.in/gUr6vtKi Source: https://lnkd.in/dYXnUHah #ETW #WindowsTroubleshooting #SystemAdministration #DiagnosticTools