proc_pid_attr(5)
๐ NAME ๐
/proc/pid/attr/ โ security-related attributes โจ (yes bestie, the security-vibes folder)
๐ธ DESCRIPTION ๐ธ
๐
/proc/pid/attr/
Okay so this directory?? The files inside it are literally an API for security modules. They're normal-looking files you can read and write to set security-related attributes. It got added to support SELinux, but the whole idea was that the API should be general enough to work for other security modules too, not just the one. And just so it makes sense, the examples below show how SELinux uses these files ๐
Heads up: this directory is only even there if your kernel was configured with CONFIG_SECURITY. No config, no folder, no cap. ๐ซถ
๐ /proc/pid/attr/current (since Linux 2.6.0)
What's in this file = the current security attributes of the process. That's it, that's the vibe.
In SELinux, this file is how you get the security context of a process. But the lore goes deep:
- Prior to Linux 2.6.11, you could not use this file to set the security context โ a write was always denied โ because SELinux limited process security transitions to
execve(2)(peep the description of/proc/pid/attr/execbelow, it's all connected ๐ซ). - Since Linux 2.6.11, SELinux lifted that restriction and started supporting
"set"operations via writes to this node if authorized by policy. Though lowkey, using this operation is only suitable for applications that are trusted to maintain any desired separation between the old and the new security contexts. Trust matters here, bestie. - Prior to Linux 2.6.28, SELinux did not let threads within a multithreaded process set their security context via this node, because that would yield an inconsistency among the security contexts of the threads sharing the same memory space. ๐
- Since Linux 2.6.28, SELinux lifted that restriction too and started supporting
"set"operations for threads within a multithreaded process if the new security context is bounded by the old security context โ where that bounded relation is defined in policy and guarantees that the new security context has a subset of the permissions of the old security context. Periodt.
Other security modules may also choose to support "set" operations via writes to this node. Everybody's invited ๐
๐ฆ /proc/pid/attr/exec (since Linux 2.6.0)
This file represents the attributes to assign to the process upon a subsequent execve(2). Future you's attributes, basically.
In SELinux, this is what you need to support role/domain transitions, and execve(2) is the preferred point to make those transitions because it offers better control over the initialization of the process in the new security label and the inheritance of state. Iconic behavior, honestly.
In SELinux, this attribute is reset on execve(2) so the new program reverts to default behavior for any execve(2) calls it may make. And in SELinux, a process can set only its own /proc/pid/attr/exec attribute. Stay in your lane, respectfully ๐
โจ /proc/pid/attr/fscreate (since Linux 2.6.0)
This file represents the attributes to assign to files created by subsequent calls to open(2), mkdir(2), symlink(2), and mknod(2).
SELinux uses this file to support creation of a file (via those system calls we just named) in a secure state, so there's no risk of inappropriate access being obtained between the time of creation and the time that the attributes get set. Chef's kiss security, no gap, no window ๐ฅ
In SELinux, this attribute is reset on execve(2), so the new program reverts to default behavior for any file creation calls it may make โ but the attribute will persist across multiple file creation calls within a program unless it's explicitly reset. And in SELinux, a process can set only its own /proc/pid/attr/fscreate attribute.
๐ /proc/pid/attr/keycreate (since Linux 2.6.18)
If a process writes a security context into this file, all subsequently created keys (add_key(2)) will be labeled with that context. Every new key gets the drip โจ
For further information, see the kernel source file Documentation/security/keys/core.rst.
๐ /proc/pid/attr/prev (since Linux 2.6.0)
This file contains the security context of the process before the last execve(2) โ aka the previous value of /proc/pid/attr/current. It's giving throwback Thursday for security contexts ๐ญ
๐ธ /proc/pid/attr/socketcreate (since Linux 2.6.18)
If a process writes a security context into this file, all subsequently created sockets will be labeled with that context. Sockets: labeled. Slay ๐ซถ
๐ SEE ALSO ๐
And that's the whole page, bestie! This one came from the Linux man-pages 6.20 era, dated 2026-02-08, and it lives under the File Formats Manual section (proc_pid_attr(5)). Go read your /proc/pid/attr/ files responsibly ๐
๐
๐ฆ where this page comes from
- arch rolling: man-pages 6.20-1 ยท BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages 6.20
- ๐ the page's license: GPL-3.0-or-later
- Copyright 1994-1995, Daniel Quinlan <Daniel.Quinlan@linux.org>
- Copyright 2002-2017, Michael Kerrisk <mtk.manpages@gmail.com>
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms