linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] docs,procfs: document /proc/PID/* access permission checks
@ 2025-01-29  0:17 Andrii Nakryiko
  2025-01-29  0:28 ` Shakeel Butt
  0 siblings, 1 reply; 2+ messages in thread
From: Andrii Nakryiko @ 2025-01-29  0:17 UTC (permalink / raw)
  To: linux-mm, akpm, linux-fsdevel, brauner, viro
  Cc: linux-kernel, bpf, kernel-team, rostedt, peterz, mingo,
	linux-trace-kernel, linux-perf-users, shakeel.butt, rppt,
	liam.howlett, surenb, kees, jannh, Andrii Nakryiko

Add a paragraph explaining what sort of capabilities a process would
need to read procfs data for some other process. Also mention that
reading data for its own process doesn't require any extra permissions.

Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
 Documentation/filesystems/proc.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 09f0aed5a08b..0e7825bb1e3a 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -128,6 +128,16 @@ process running on the system, which is named after the process ID (PID).
 The link  'self'  points to  the process reading the file system. Each process
 subdirectory has the entries listed in Table 1-1.
 
+A process can read its own information from /proc/PID/* with no extra
+permissions. When reading /proc/PID/* information for other processes, reading
+process is required to have either CAP_SYS_PTRACE capability with
+PTRACE_MODE_READ access permissions, or, alternatively, CAP_PERFMON
+capability. This applies to all read-only information like `maps`, `environ`,
+`pagemap`, etc. The only exception is `mem` file due to its read-write nature,
+which requires CAP_SYS_PTRACE capabilities with more elevated
+PTRACE_MODE_ATTACH permissions; CAP_PERFMON capability does not grant access
+to /proc/PID/mem for other processes.
+
 Note that an open file descriptor to /proc/<pid> or to any of its
 contained files or subdirectories does not prevent <pid> being reused
 for some other process in the event that <pid> exits. Operations on
-- 
2.43.5



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] docs,procfs: document /proc/PID/* access permission checks
  2025-01-29  0:17 [PATCH] docs,procfs: document /proc/PID/* access permission checks Andrii Nakryiko
@ 2025-01-29  0:28 ` Shakeel Butt
  0 siblings, 0 replies; 2+ messages in thread
From: Shakeel Butt @ 2025-01-29  0:28 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: linux-mm, akpm, linux-fsdevel, brauner, viro, linux-kernel, bpf,
	kernel-team, rostedt, peterz, mingo, linux-trace-kernel,
	linux-perf-users, rppt, liam.howlett, surenb, kees, jannh

On Tue, Jan 28, 2025 at 04:17:47PM -0800, Andrii Nakryiko wrote:
> Add a paragraph explaining what sort of capabilities a process would
> need to read procfs data for some other process. Also mention that
> reading data for its own process doesn't require any extra permissions.
> 
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-01-29  0:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-29  0:17 [PATCH] docs,procfs: document /proc/PID/* access permission checks Andrii Nakryiko
2025-01-29  0:28 ` Shakeel Butt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox