A file descriptor table is a per-process data structure that maps small integer file descriptor values to open files, sockets, pipes, or other I O objects. The operating system uses it to track access mode, position, and lifetime for each open handle.
What a file descriptor table does
A file descriptor table is the process-local lookup structure that turns a small integer into a live I/O reference. That reference may point to a file, socket, pipe, device, or similar kernel-managed object, and it carries the state needed for reads, writes, offsets, and eventual close semantics.
The key idea is indirection. Applications do not usually manipulate the underlying object directly; they pass integers to system calls, and the operating system resolves them through the table. That design makes descriptors cheap to pass around, but it also means the table becomes a critical boundary between process logic and kernel-managed resources.
How the table relates to open handles and process state
Each entry in the table represents an open handle in the context of one process. Multiple descriptors can refer to the same underlying open file description, which is why duplicated descriptors can share file position and status flags even when they have different integer values. That distinction matters when software forks, duplicates descriptors, or redirects standard input, output, and error.
The table also helps define lifetime. A process can keep an object alive only as long as at least one descriptor still references it. When a descriptor is closed, the kernel can eventually release the underlying resource if no other reference remains. Because of that lifecycle, descriptor ownership is not just a bookkeeping detail, it determines when resources are retained, shared, or freed.
Why the structure matters for correctness and security
File descriptor tables are part of the control plane for process I/O, so mistakes around inheritance, duplication, or cleanup can produce real security consequences. Unintended descriptor inheritance can expose files or sockets to child processes, and incorrect cleanup can leave sensitive resources reachable longer than intended. A leaked descriptor can also keep a privileged file, pipe, or network connection open after the code that created it has moved on.
Descriptor handling is also a common source of subtle bugs in concurrent and long-running software. A descriptor reused after close, or one that is assumed to still refer to the same object, can cause logic errors, data corruption, or unintended access to the wrong resource. In practice, that makes descriptor hygiene an important part of defensive programming, especially in services that spawn workers, handle many connections, or manage mixed trust inputs.
Common operational patterns and debugging signals
Practitioners often inspect descriptor tables when diagnosing file descriptor leaks, unexpected open files, socket exhaustion, or odd process-to-process resource sharing. The table is a useful lens for understanding why a process cannot release a file, why a network connection persists, or why a service appears to hold more resources than its code suggests.
Typical warning signs include steadily rising descriptor counts, objects that remain open after shutdown, inherited handles in subprocesses, and failures that appear only after many repeated requests or restarts. Those symptoms often point to missing closes, incorrect duplication rules, or code paths that fail to clean up descriptors on error.
Risk and Threat Considerations
File descriptor tables can create security exposure when a process inherits, leaks, or mishandles handles that should have been closed or isolated. That risk is especially important in privileged services, sandbox boundaries, and multi-process applications where an unexpected descriptor can preserve access to sensitive files, sockets, or IPC channels.
Failure mechanism: A process keeps a sensitive descriptor open longer than intended, duplicates it into a child process, or reuses a stale integer after close, allowing unintended access, information leakage, or control of the wrong I/O object.
Impact: The result can include leaked data, unintended privilege retention, socket hijacking, resource exhaustion, or a harder-to-detect persistence path for malicious or buggy code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Descriptor lifecycle and inheritance affect controlled access to system resources. |
| Recommendation — Review open-handle handling and revoke unintended access paths promptly. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Descriptor inheritance can preserve more resource access than a process needs. |
| SC-39 — Process Isolation | Per-process descriptor tables are part of isolating one process's I/O state from another. | |
| Recommendation — Limit inherited descriptors and close unneeded handles to reduce privilege exposure. Constrain inter-process handle sharing so one process cannot reach another's I/O state. | ||
| ISO/IEC 27001:2022 | A.8.2 — Information classification | Sensitive file and socket handles should be treated according to their protection needs. |
| Recommendation — Classify sensitive handles and apply handling rules that match the data they expose. | ||
| MITRE ATT&CK | T1057 — Process Discovery | Open-handle enumeration is commonly used to understand process state and reachable resources. |
| Recommendation — Monitor for process inspection that reveals open descriptors and reachable targets. | ||
Practitioner Guidance
What to watch for: Treat descriptor lifecycle as part of security-critical resource management, not just cleanup code. Review process creation, descriptor inheritance, and close-on-exec behaviour carefully, especially in services that handle secrets, privileged files, or long-lived network sessions.
Practitioner note: When a defect is described as a resource leak, an unexplained open handle, or an access anomaly after fork or exec, the descriptor table is often the first place to investigate.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org