Linux

Software Engineering / 18 Sep 2026 / 5 min read

Linux signalfd Converts Selected Signals into Descriptor Reads

A signal included in a signalfd mask can become readable state on a file descriptor instead of invoking an asynchronous signal handler, provided that the signal is blocked from ordinary delivery in the relevant thread. This changes the interface boundary: signal arrival can participate in the same descriptor-oriented event loop as sockets, pipes, and other pollable objects. The mechanism does not replace Linux signal semantics. Signal generation, process and thread signal masks, pending state, standard-signal coalescing, real-time signal queuing, and delivery rules still apply. signalfd changes the consumption interface for signals selected by its mask.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 7 min read

Linux signalfd Converts Pending Signals into Descriptor Reads

Linux signalfd gives selected signals a descriptor-oriented consumption path. Instead of transferring control into an asynchronous handler, a process can block those signals, associate them with a signalfd object, and consume pending instances through read(). The descriptor can also participate in poll(), select(), and epoll, placing signal reception beside sockets, timers, and other readiness sources. This interface is Linux-specific. The signal mask, pending-signal rules, and descriptor operations come from Linux and POSIX signal semantics where applicable; they are not properties of the C language itself.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 6 min read

Linux renameat2 Makes Path-Replacement Policy Atomic

A pathname rename changes directory entries while open file descriptors continue to refer to the same underlying objects. Linux renameat2() adds policy to that namespace update: a caller can reject replacement, exchange two existing names, or request a whiteout for union-filesystem operation. These policies are executed as part of the rename operation rather than as checks performed separately in userspace. The interface is Linux-specific. A zero flags argument gives renameat() behavior, while nonzero flags add Linux semantics that also depend on support from the mounted filesystem.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 6 min read

Linux pidfd Binds Process Operations to Stable Kernel References

A numeric process ID is a name in a PID namespace, not a durable handle to one process lifetime. After a process exits and its PID becomes available for reuse, a later process can receive the same number. Linux PID file descriptors add a different interface boundary: a pidfd is a file descriptor referring to a particular task, so later operations can target that kernel reference rather than resolving the numeric PID again.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 5 min read

Linux pidfd Binds Process Operations to Stable Kernel Identity

A numeric PID names a process through a namespace lookup. That number can later be reused after the process exits and is reaped. Linux PID file descriptors change the boundary: a pidfd is a file descriptor referring to a particular task, so later operations can target that reference instead of resolving the numeric PID again. This is Linux-specific process-management behavior. It is not a property of POSIX process identifiers or of the C language.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 6 min read

Linux openat2 Constrains Path Resolution Inside a Directory Boundary

A pathname passed to openat2() can be resolved relative to a directory file descriptor while the kernel enforces restrictions on the resolution process itself. That distinction matters when a process accepts path components from a less-trusted source. A string check can inspect the pathname text, but it cannot by itself freeze the filesystem namespace while lookup proceeds. openat2() places the policy beside the lookup. Its struct open_how separates ordinary open flags from resolve flags that constrain traversal. The resulting boundary is about resolution semantics, not merely the spelling of a path.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 5 min read

Linux O_PATH Separates Object Reference From I/O Authority

open() usually combines two effects: pathname resolution selects a filesystem object, then the returned file descriptor carries an access mode for data I/O. Linux O_PATH splits those effects. A successful open(path, O_PATH) returns a descriptor that refers to the selected object while ordinary read() and write() through that descriptor are not permitted. That split is useful anywhere a process needs a durable kernel reference for later metadata or pathname-relative operations without opening the object for data transfer. It also changes race analysis: later operations can start from the descriptor rather than resolving the original pathname again.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 4 min read

Linux memfd Seals Turn Mutable Memory Files into Enforced State Transitions

A file created by memfd_create() can begin as mutable storage and later acquire kernel-enforced restrictions that apply to the underlying file rather than to one descriptor. With MFD_ALLOW_SEALING, a process can add seals through fcntl(F_ADD_SEALS) and make selected mutations unavailable to every holder of that file. This creates a state transition that ordinary descriptor permissions do not express. A producer can populate bytes, fix the file’s size, and then publish the descriptor with restrictions that remain attached even after the descriptor crosses a process boundary.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 6 min read

Linux memfd Seals Convert Mutable Anonymous Files into Restricted Capabilities

A file descriptor returned by memfd_create() can begin as a writable, resizable anonymous file and later become an object whose permitted mutation operations have been permanently reduced. Linux implements that transition with file seals. The mechanism is attached to the underlying file rather than to one descriptor, so passing a duplicate descriptor across a process boundary does not create an independent sealing state. This property makes sealing more than a convenience around temporary storage. It changes the authority carried by every descriptor that refers to the same memfd object. The transition is monotonic: seals can be added, but they cannot be removed.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 5 min read

Linux inotify Reports Directory-Entry Events, Not Durable Path Identity

An inotify watch does not make a pathname a durable identifier. Linux attaches a watch to a filesystem object selected when inotify_add_watch() succeeds, then emits records describing activity associated with watched objects and directory entries. Names can move, objects can disappear, and event delivery can lose detail when the queue overflows. That boundary matters for file synchronizers, configuration reloaders, indexers, and service supervisors. An event stream can signal that local filesystem state changed, but reconstructing authoritative state still depends on filesystem operations performed after the event.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 5 min read

Linux eventfd Represents Counter State Through Descriptor Readiness

An eventfd object stores an unsigned 64-bit counter in the kernel and exposes that state through a file descriptor. Writes add to the counter under defined bounds; reads consume counter state; readiness interfaces expose whether an operation can proceed without blocking. The result is a compact synchronization boundary that fits descriptor-oriented event loops without turning the counter into a byte stream. The interface is Linux-specific. Its guarantees come from the eventfd system-call contract and kernel descriptor semantics, not from the C language or POSIX.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 8 min read

Linux copy_file_range Separates Copy Semantics From Data Movement

copy_file_range() asks Linux to copy bytes between regular files without requiring the application to shuttle those bytes through a user-space buffer. The call defines a byte-range operation, but it does not prescribe the physical transfer mechanism. A filesystem can perform ordinary data movement, use a copy-on-write sharing mechanism such as reflink, or employ another supported acceleration path while preserving the visible file contents required by the operation. That separation is the central API boundary. Applications specify source and destination ranges and observe the returned byte count. The kernel and filesystem retain latitude over the mechanism used to realize the copy.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 8 min read

Linux close_range Makes Descriptor-Table Cleanup a Range Operation

A process preparing to execute another program often needs a simple descriptor invariant: standard input, output, and error remain available, while unrelated descriptors do not cross the execution boundary. Closing descriptors one at a time can turn that invariant into an enumeration problem. Linux close_range() instead applies an operation to an inclusive numeric interval in the calling task’s file-descriptor table. The interface is small, but its semantics reach into descriptor-table sharing, execve() inheritance, concurrent descriptor allocation, and privilege transitions. The flags select more than implementation strategy: they determine whether descriptors disappear immediately, become close-on-exec, or are first separated from a table shared with other tasks.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 5 min read

Linux close_range Makes Descriptor Cleanup a Table Operation

A process preparing for execve() often needs a simple invariant: descriptors above a small allowlist must not survive into the new program. Closing descriptor numbers one by one turns that invariant into an enumeration problem. Linux close_range() expresses it directly as an operation over an inclusive interval of the calling task’s file descriptor table. The interface is Linux-specific. Its behavior belongs to Linux file-table and system-call semantics, not to the C language or a portable POSIX guarantee.

Software Engineering Linux

Linux / 18 Sep 2026 / 6 min read

Landlock Rulesets Add Process-Local Access Control

A Linux process can voluntarily remove access that its UID, capabilities, mount namespace, and other security layers would otherwise permit. Landlock implements this as a stackable Linux Security Module: a process creates a ruleset, adds allowed objects, then places itself in a Landlock domain. The resulting policy is an additional restriction. It does not grant access denied by DAC, ACLs, SELinux, AppArmor, mount permissions, or another active control. Once enforced, the Landlock layer cannot be removed from that thread; later Landlock domains can only add restrictions.

Linux Security

Software Engineering / 18 Sep 2026 / 4 min read

Landlock Handled Rights Define a Deny-by-Default Sandbox Boundary

A Landlock ruleset does not implicitly deny every operation known to the running kernel. It first declares which access rights it handles. Once the ruleset is enforced, those handled actions are denied by default unless a matching rule grants them. That explicit boundary is central to Landlock compatibility. User space can restrict rights it knows and has tested while a newer kernel may expose additional rights that an older binary never named.

Software Engineering Linux

Cybersecurity / 18 Sep 2026 / 7 min read

Landlock Adds a Process-Local Restriction Layer to Linux Access Control

A service may start with every filesystem permission granted to its Unix identity, yet only need a small subset after initialization. Changing the service account or mount topology can reduce that authority, but both are deployment-wide decisions. Linux Landlock provides a different boundary: a process can add restrictions to itself and its descendants without receiving privilege to grant new access. Landlock is a stackable Linux Security Module. Its rules are additional constraints, not replacements for discretionary access control, capabilities, or other active LSM policy. A Landlock rule cannot turn a denied operation into an allowed one. It can only remove authority that the process would otherwise possess.

Cybersecurity Linux

Software Engineering / 18 Sep 2026 / 4 min read

io_uring Links Serialize Dependent Requests

Two adjacent io_uring submission queue entries are normally independent requests. Setting IOSQE_IO_LINK on the first changes that relationship: the next request does not start before the linked request completes. Repeating the flag forms an ordered chain inside one submission batch. The ordering property is narrower than global queue serialization. Requests outside the chain can still run independently, and separate chains can overlap. A link therefore expresses dependency between specific SQEs rather than imposing a barrier on the entire ring.

Software Engineering Linux

Cybersecurity / 18 Sep 2026 / 7 min read

fs-verity Binds File Reads to a Merkle Tree Digest

A package manager can place an executable on a writable filesystem, close it, and later expect every byte returned from that file to match a previously approved object. Ordinary permissions can stop cooperative writers, but they do not turn file contents into a cryptographically identified object. Linux fs-verity supplies that narrower property for individual files: after verity is enabled, file data becomes read-only and reads are checked against a Merkle tree rooted in a stable file digest.

Cybersecurity Linux

Cybersecurity / 18 Sep 2026 / 6 min read

Fanotify Permission Events Put File Access Behind a Userspace Decision

A process calls execve() for a binary on a monitored filesystem, but the kernel does not immediately complete the execution open. A fanotify group has requested FAN_OPEN_EXEC_PERM, so the access waits while a userspace listener receives an event and returns FAN_ALLOW or FAN_DENY. The mechanism inserts a synchronous userspace decision into a filesystem operation that would otherwise proceed after ordinary kernel permission checks. That interception point is useful for policy engines that need information outside normal inode permissions, but it creates a distinct enforcement boundary. Availability now depends on a userspace responder, event coverage depends on the selected fanotify marks and event classes, and the mechanism does not convert every form of file use into a mediated operation.

Cybersecurity Linux

Software Engineering / 18 Sep 2026 / 4 min read

eventfd Turns Counter State into Descriptor Readiness

An eventfd descriptor becomes readable when its kernel-maintained counter is greater than zero. A write does not enqueue a variable-length message. It adds an unsigned 64-bit value to that counter, turning accumulated notification state into ordinary file-descriptor readiness. This boundary is useful in systems where a thread or kernel facility must wake an event loop without introducing a byte-stream protocol. The state carried by the descriptor is deliberately narrow: a counter, a readiness condition, and two possible consumption semantics.

Software Engineering Linux

Linux / 18 Sep 2026 / 5 min read

eventfd Aggregates Notifications in a Kernel Counter

An eventfd can absorb several notification writes before userspace services the descriptor. The kernel stores those writes in a 64-bit counter, so readiness represents pending counter state rather than a queue containing one record per notification. That distinction matters in event loops. A producer can add values while a consumer is occupied, and the next read can collapse accumulated state into one result. With EFD_SEMAPHORE, the same object exposes a different consumption rule without changing its readiness model.

Linux eventfd

Software Engineering / 18 Sep 2026 / 6 min read

EPOLLEXCLUSIVE Limits Wakeups Across Competing epoll Instances

EPOLLEXCLUSIVE changes which epoll waiters are awakened when several epoll instances monitor the same target. Without the flag, a readiness event can be delivered to every attached epoll instance. With exclusive registration, Linux can wake a smaller subset, reducing redundant scheduling in configurations that otherwise create a thundering herd. The flag changes wakeup distribution. It does not assign permanent ownership of the target descriptor, serialize I/O, or guarantee that exactly one application thread consumes each unit of work.

Software Engineering Linux

Linux / 18 Sep 2026 / 4 min read

EPOLLEXCLUSIVE Limits Wakeups Across Competing epoll Instances

A single ready socket can wake several threads when each thread waits on a different epoll instance that watches that socket. Linux provides EPOLLEXCLUSIVE to narrow that wakeup fan-out: among epoll instances that registered the target with the flag, a readiness event wakes one or more rather than all of them. The distinction is deliberately weaker than “exactly one waiter.” EPOLLEXCLUSIVE changes notification selection across epoll instances. It does not transfer ownership of the file descriptor, serialize all I/O, or guarantee that only one thread can observe useful work.

Linux epoll