Re: [PATCH v8 10/11] docs: proc: add documentation for "hidepid=4" and "subset=pidfs" options and new mount behavior
From: Andy Lutomirski <luto@kernel.org>
Date: 2020-02-10 18:29:39
Also in:
linux-fsdevel, linux-security-module, lkml
On Mon, Feb 10, 2020 at 7:06 AM Alexey Gladkov [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Signed-off-by: Alexey Gladkov <redacted> --- Documentation/filesystems/proc.txt | 53 ++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 99ca040e3f90..4741fd092f36 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt@@ -50,6 +50,8 @@ Table of Contents 4 Configuring procfs 4.1 Mount options + 5 Filesystem behavior + ------------------------------------------------------------------------------ Preface ------------------------------------------------------------------------------@@ -2021,6 +2023,7 @@ The following mount options are supported: hidepid= Set /proc/<pid>/ access mode. gid= Set the group authorized to learn processes information. + subset= Show only the specified subset of procfs. hidepid=0 means classic mode - everybody may access all /proc/<pid>/ directories (default).@@ -2042,6 +2045,56 @@ information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, etc. +hidepid=4 means that procfs should only contain /proc/<pid>/ directories +that the caller can ptrace.
I have a couple of minor nits here. First, perhaps we could stop using magic numbers and use words. hidepid=ptraceable is actually comprehensible, whereas hidepid=4 requires looking up what '4' means. Second, there is PTRACE_MODE_ATTACH and PTRACE_MODE_READ. Which is it?
+ gid= defines a group authorized to learn processes information otherwise prohibited by hidepid=. If you use some daemon like identd which needs to learn information about processes information, just add identd to this group.
How is this better than just creating an entirely separate mount a different hidepid and a different gid owning it? In any event, usually gid= means that this gid is the group owner of inodes. Let's call it something different. gid_override_hidepid might be credible. But it's also really weird -- do different groups really see different contents when they read a directory?