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/exec below, 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
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms