Preface:
--------
This is patchset v10 to modernize procfs and make it able to support multiple
private instances per the same pid namespace.
This patchset can be applied on top of:
git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 4b871ce26ab2
Procfs modernization:
---------------------
Historically procfs was always tied to pid namespaces, during pid
namespace creation we internally create a procfs mount for it. However,
this has the effect that all new procfs mounts are just a mirror of the
internal one, any change, any mount option update, any new future
introduction will propagate to all other procfs mounts that are in the
same pid namespace.
This may have solved several use cases in that time. However today we
face new requirements, and making procfs able to support new private
instances inside same pid namespace seems a major point. If we want to
to introduce new features and security mechanisms we have to make sure
first that we do not break existing usecases. Supporting private procfs
instances will allow to support new features and behaviour without
propagating it to all other procfs mounts.
Today procfs is more of a burden especially to some Embedded, IoT,
sandbox, container use cases. In user space we are over-mounting null
or inaccessible files on top to hide files and information. If we want
to hide pids we have to create PID namespaces otherwise mount options
propagate to all other proc mounts, changing a mount option value in one
mount will propagate to all other proc mounts. If we want to introduce
new features, then they will propagate to all other mounts too, resulting
either maybe new useful functionality or maybe breaking stuff. We have
also to note that userspace should not workaround procfs, the kernel
should just provide a sane simple interface.
In this regard several developers and maintainers pointed out that
there are problems with procfs and it has to be modernized:
"Here's another one: split up and modernize /proc." by Andy Lutomirski [1]
Discussion about kernel pointer leaks:
"And yes, as Kees and Daniel mentioned, it's definitely not just dmesg.
In fact, the primary things tend to be /proc and /sys, not dmesg
itself." By Linus Torvalds [2]
Lot of other areas in the kernel and filesystems have been updated to be
able to support private instances, devpts is one major example [3].
Which will be used for:
1) Embedded systems and IoT: usually we have one supervisor for
apps, we have some lightweight sandbox support, however if we create
pid namespaces we have to manage all the processes inside too,
where our goal is to be able to run a bunch of apps each one inside
its own mount namespace, maybe use network namespaces for vlans
setups, but right now we only want mount namespaces, without all the
other complexity. We want procfs to behave more like a real file system,
and block access to inodes that belong to other users. The 'hidepid=' will
not work since it is a shared mount option.
2) Containers, sandboxes and Private instances of file systems - devpts case
Historically, lot of file systems inside Linux kernel view when instantiated
were just a mirror of an already created and mounted filesystem. This was the
case of devpts filesystem, it seems at that time the requirements were to
optimize things and reuse the same memory, etc. This design used to work but not
anymore with today's containers, IoT, hostile environments and all the privacy
challenges that Linux faces.
In that regards, devpts was updated so that each new mounts is a total
independent file system by the following patches:
"devpts: Make each mount of devpts an independent filesystem" by
Eric W. Biederman [3] [4]
3) Linux Security Modules have multiple ptrace paths inside some
subsystems, however inside procfs, the implementation does not guarantee
that the ptrace() check which triggers the security_ptrace_check() hook
will always run. We have the 'hidepid' mount option that can be used to
force the ptrace_may_access() check inside has_pid_permissions() to run.
The problem is that 'hidepid' is per pid namespace and not attached to
the mount point, any remount or modification of 'hidepid' will propagate
to all other procfs mounts.
This also does not allow to support Yama LSM easily in desktop and user
sessions. Yama ptrace scope which restricts ptrace and some other
syscalls to be allowed only on inferiors, can be updated to have a
per-task context, where the context will be inherited during fork(),
clone() and preserved across execve(). If we support multiple private
procfs instances, then we may force the ptrace_may_access() on
/proc/<pids>/ to always run inside that new procfs instances. This will
allow to specifiy on user sessions if we should populate procfs with
pids that the user can ptrace or not.
By using Yama ptrace scope, some restricted users will only be able to see
inferiors inside /proc, they won't even be able to see their other
processes. Some software like Chromium, Firefox's crash handler, Wine
and others are already using Yama to restrict which processes can be
ptracable. With this change this will give the possibility to restrict
/proc/<pids>/ but more importantly this will give desktop users a
generic and usuable way to specifiy which users should see all processes
and which user can not.
Side notes:
* This covers the lack of seccomp where it is not able to parse
arguments, it is easy to install a seccomp filter on direct syscalls
that operate on pids, however /proc/<pid>/ is a Linux ABI using
filesystem syscalls. With this change all LSMs should be able to analyze
open/read/write/close... on /proc/<pid>/
4) This will allow to implement new features either in kernel or
userspace without having to worry about procfs.
In containers, sandboxes, etc we have workarounds to hide some /proc
inodes, this should be supported natively without doing extra complex
work, the kernel should be able to support sane options that work with
today and future Linux use cases.
5) Creation of new superblock with all procfs options for each procfs
mount will fix the ignoring of mount options. The problem is that the
second mount of procfs in the same pid namespace ignores the mount
options. The mount options are ignored without error until procfs is
remounted.
Before:
# grep ^proc /proc/mounts
proc /proc proc rw,relatime,hidepid=2 0 0
# strace -e mount mount -o hidepid=1 -t proc proc /tmp/proc
mount("proc", "/tmp/proc", "proc", 0, "hidepid=1") = 0
+++ exited with 0 +++
# grep ^proc /proc/mounts
proc /proc proc rw,relatime,hidepid=2 0 0
proc /tmp/proc proc rw,relatime,hidepid=2 0 0
# mount -o remount,hidepid=1 -t proc proc /tmp/proc
# grep ^proc /proc/mounts
proc /proc proc rw,relatime,hidepid=1 0 0
proc /tmp/proc proc rw,relatime,hidepid=1 0 0
After:
# grep ^proc /proc/mounts
proc /proc proc rw,relatime,hidepid=ptraceable 0 0
# mount -o hidepid=invisible -t proc proc /tmp/proc
# grep ^proc /proc/mounts
proc /proc proc rw,relatime,hidepid=ptraceable 0 0
proc /tmp/proc proc rw,relatime,hidepid=invisible 0 0
Introduced changes:
-------------------
Each mount of procfs creates a separate procfs instance with its own
mount options.
This series adds few new mount options:
* New 'hidepid=ptraceable' or 'hidepid=4' mount option to show only ptraceable
processes in the procfs. This allows to support lightweight sandboxes in
Embedded Linux, also solves the case for LSM where now with this mount option,
we make sure that they have a ptrace path in procfs.
* 'subset=pid' that allows to hide non-pid inodes from procfs. It can be used
in containers and sandboxes, as these are already trying to hide and block
access to procfs inodes anyway.
ChangeLog:
----------
# v10:
* 'subset=pidfs' renamed to 'subset=pid' as suggested by Alexey Dobriyan.
* Include Reviewed-by tags.
# v9:
* Rebase on top of Eric W. Biederman's procfs changes.
* Add human readable values of 'hidepid' as suggested by Andy Lutomirski.
# v8:
* Started using RCU lock to clean dcache entries as suggested by Linus Torvalds.
# v7:
* 'pidonly=1' renamed to 'subset=pidfs' as suggested by Alexey Dobriyan.
* HIDEPID_* moved to uapi/ as they are user interface to mount().
Suggested-by Alexey Dobriyan <[email protected]>
# v6:
* 'hidepid=' and 'gid=' mount options are moved from pid namespace to superblock.
* 'newinstance' mount option removed as suggested by Eric W. Biederman.
Mount of procfs always creates a new instance.
* 'limit_pids' renamed to 'hidepid=3'.
* I took into account the comment of Linus Torvalds [7].
* Documentation added.
# v5:
* Fixed a bug that caused a problem with the Fedora boot.
* The 'pidonly' option is visible among the mount options.
# v2:
* Renamed mount options to 'newinstance' and 'pids='
Suggested-by: Andy Lutomirski <[email protected]>
* Fixed order of commit, Suggested-by: Andy Lutomirski <[email protected]>
* Many bug fixes.
# v1:
* Removed 'unshared' mount option and replaced it with 'limit_pids'
which is attached to the current procfs mount.
Suggested-by Andy Lutomirski <[email protected]>
* Do not fill dcache with pid entries that we can not ptrace.
* Many bug fixes.
References:
-----------
[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2017-January/004215.html
[2] http://www.openwall.com/lists/kernel-hardening/2017/10/05/5
[3] https://lwn.net/Articles/689539/
[4] http://lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.14
[5] https://lkml.org/lkml/2017/5/2/407
[6] https://lkml.org/lkml/2017/5/3/357
[7] https://lkml.org/lkml/2018/5/11/505
Alexey Gladkov (9):
proc: rename struct proc_fs_info to proc_fs_opts
proc: allow to mount many instances of proc in one pid namespace
proc: move hide_pid, pid_gid from pid_namespace to proc_fs_info
proc: instantiate only pids that we can ptrace on 'hidepid=4' mount
option
proc: add option to mount only a pids subset
docs: proc: add documentation for "hidepid=4" and "subset=pid" options
and new mount behavior
proc: move hidepid values to uapi as they are user interface to mount
proc: use human-readable values for hidehid
proc: use named enums for better readability
Documentation/filesystems/proc.txt | 93 ++++++++++++++++-----
fs/proc/base.c | 48 +++++++----
fs/proc/generic.c | 9 ++
fs/proc/inode.c | 28 +++++--
fs/proc/root.c | 128 +++++++++++++++++++++++------
fs/proc/self.c | 6 +-
fs/proc/thread_self.c | 6 +-
fs/proc_namespace.c | 14 ++--
include/linux/pid_namespace.h | 8 --
include/linux/proc_fs.h | 22 +++++
include/uapi/linux/proc_fs.h | 13 +++
11 files changed, 290 insertions(+), 85 deletions(-)
create mode 100644 include/uapi/linux/proc_fs.h
--
2.25.2
The hidepid parameter values are becoming more and more and it becomes
difficult to remember what each new magic number means.
Suggested-by: Andy Lutomirski <[email protected]>
Reviewed-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Alexey Gladkov <[email protected]>
---
Documentation/filesystems/proc.txt | 52 +++++++++++++++---------------
fs/proc/inode.c | 13 +++++++-
fs/proc/root.c | 36 +++++++++++++++++++--
3 files changed, 71 insertions(+), 30 deletions(-)
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index bd0e0ab85048..af47672cb2cb 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -2025,28 +2025,28 @@ The following mount options are supported:
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).
-
-hidepid=1 means users may not access any /proc/<pid>/ directories but their
-own. Sensitive files like cmdline, sched*, status are now protected against
-other users. This makes it impossible to learn whether any user runs
-specific program (given the program doesn't reveal itself by its behaviour).
-As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
-poorly written programs passing sensitive information via program arguments are
-now protected against local eavesdroppers.
-
-hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
-users. It doesn't mean that it hides a fact whether a process with a specific
-pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
-but it hides process' uid and gid, which may be learned by stat()'ing
-/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
-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.
+hidepid=off or hidepid=0 means classic mode - everybody may access all
+/proc/<pid>/ directories (default).
+
+hidepid=noaccess or hidepid=1 means users may not access any /proc/<pid>/
+directories but their own. Sensitive files like cmdline, sched*, status are now
+protected against other users. This makes it impossible to learn whether any
+user runs specific program (given the program doesn't reveal itself by its
+behaviour). As an additional bonus, as /proc/<pid>/cmdline is unaccessible for
+other users, poorly written programs passing sensitive information via program
+arguments are now protected against local eavesdroppers.
+
+hidepid=invisible or hidepid=2 means hidepid=noaccess plus all /proc/<pid>/ will
+be fully invisible to other users. It doesn't mean that it hides a fact whether
+a process with a specific pid value exists (it can be learned by other means,
+e.g. by "kill -0 $PID"), but it hides process' uid and gid, which may be learned
+by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task
+of gathering 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=ptraceable or hidepid=4 means that procfs should only contain
+/proc/<pid>/ directories that the caller can ptrace.
gid= defines a group authorized to learn processes information otherwise
prohibited by hidepid=. If you use some daemon like identd which needs to learn
@@ -2093,8 +2093,8 @@ creates a new procfs instance. Mount options affect own procfs instance.
It means that it became possible to have several procfs instances
displaying tasks with different filtering options in one pid namespace.
-# mount -o hidepid=2 -t proc proc /proc
-# mount -o hidepid=1 -t proc proc /tmp/proc
+# mount -o hidepid=invisible -t proc proc /proc
+# mount -o hidepid=noaccess -t proc proc /tmp/proc
# grep ^proc /proc/mounts
-proc /proc proc rw,relatime,hidepid=2 0 0
-proc /tmp/proc proc rw,relatime,hidepid=1 0 0
+proc /proc proc rw,relatime,hidepid=invisible 0 0
+proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index e6577ce6027b..f01fb4bed75c 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -165,6 +165,17 @@ void proc_invalidate_siblings_dcache(struct hlist_head *inodes, spinlock_t *lock
deactivate_super(old_sb);
}
+static inline const char *hidepid2str(int v)
+{
+ switch (v) {
+ case HIDEPID_OFF: return "off";
+ case HIDEPID_NO_ACCESS: return "noaccess";
+ case HIDEPID_INVISIBLE: return "invisible";
+ case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
+ }
+ BUG();
+}
+
static int proc_show_options(struct seq_file *seq, struct dentry *root)
{
struct proc_fs_info *fs_info = proc_sb_info(root->d_sb);
@@ -172,7 +183,7 @@ static int proc_show_options(struct seq_file *seq, struct dentry *root)
if (!gid_eq(fs_info->pid_gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
if (fs_info->hide_pid != HIDEPID_OFF)
- seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
+ seq_printf(seq, ",hidepid=%s", hidepid2str(fs_info->hide_pid));
if (fs_info->pidonly != PROC_PIDONLY_OFF)
seq_printf(seq, ",subset=pid");
diff --git a/fs/proc/root.c b/fs/proc/root.c
index dbcd96f07c7a..ba782d6e6197 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -45,7 +45,7 @@ enum proc_param {
static const struct fs_parameter_spec proc_fs_parameters[] = {
fsparam_u32("gid", Opt_gid),
- fsparam_u32("hidepid", Opt_hidepid),
+ fsparam_string("hidepid", Opt_hidepid),
fsparam_string("subset", Opt_subset),
{}
};
@@ -58,6 +58,35 @@ static inline int valid_hidepid(unsigned int value)
value == HIDEPID_NOT_PTRACEABLE);
}
+static int proc_parse_hidepid_param(struct fs_context *fc, struct fs_parameter *param)
+{
+ struct proc_fs_context *ctx = fc->fs_private;
+ struct fs_parameter_spec hidepid_u32_spec = fsparam_u32("hidepid", Opt_hidepid);
+ struct fs_parse_result result;
+ int base = (unsigned long)hidepid_u32_spec.data;
+
+ if (param->type != fs_value_is_string)
+ return invalf(fc, "proc: unexpected type of hidepid value\n");
+
+ if (!kstrtouint(param->string, base, &result.uint_32)) {
+ ctx->hidepid = result.uint_32;
+ return 0;
+ }
+
+ if (!strcmp(param->string, "off"))
+ ctx->hidepid = HIDEPID_OFF;
+ else if (!strcmp(param->string, "noaccess"))
+ ctx->hidepid = HIDEPID_NO_ACCESS;
+ else if (!strcmp(param->string, "invisible"))
+ ctx->hidepid = HIDEPID_INVISIBLE;
+ else if (!strcmp(param->string, "ptraceable"))
+ ctx->hidepid = HIDEPID_NOT_PTRACEABLE;
+ else
+ return invalf(fc, "proc: unknown value of hidepid - %s\n", param->string);
+
+ return 0;
+}
+
static int proc_parse_subset_param(struct fs_context *fc, char *value)
{
struct proc_fs_context *ctx = fc->fs_private;
@@ -97,9 +126,10 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
break;
case Opt_hidepid:
- if (!valid_hidepid(result.uint_32))
+ if (proc_parse_hidepid_param(fc, param))
+ return -EINVAL;
+ if (!valid_hidepid(ctx->hidepid))
return invalf(fc, "proc: unknown value of hidepid.\n");
- ctx->hidepid = result.uint_32;
break;
case Opt_subset:
--
2.25.2
Move hide_pid and pid_gid parameters inside procfs fs_info struct
instead of making them per pid namespace. Since we have a multiple
procfs instances per pid namespace we need to make sure that all
proc-specific parameters are also per-superblock.
Reviewed-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Alexey Gladkov <[email protected]>
---
fs/proc/base.c | 18 +++++++++---------
fs/proc/inode.c | 9 ++++-----
fs/proc/root.c | 4 ++--
include/linux/pid_namespace.h | 8 --------
include/linux/proc_fs.h | 9 +++++++++
5 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3b9155a69ade..43a28907baf9 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -697,13 +697,13 @@ int proc_setattr(struct dentry *dentry, struct iattr *attr)
* May current process learn task's sched/cmdline info (for hide_pid_min=1)
* or euid/egid (for hide_pid_min=2)?
*/
-static bool has_pid_permissions(struct pid_namespace *pid,
+static bool has_pid_permissions(struct proc_fs_info *fs_info,
struct task_struct *task,
int hide_pid_min)
{
- if (pid->hide_pid < hide_pid_min)
+ if (fs_info->hide_pid < hide_pid_min)
return true;
- if (in_group_p(pid->pid_gid))
+ if (in_group_p(fs_info->pid_gid))
return true;
return ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS);
}
@@ -711,18 +711,18 @@ static bool has_pid_permissions(struct pid_namespace *pid,
static int proc_pid_permission(struct inode *inode, int mask)
{
- struct pid_namespace *pid = proc_pid_ns(inode);
+ struct proc_fs_info *fs_info = proc_sb_info(inode->i_sb);
struct task_struct *task;
bool has_perms;
task = get_proc_task(inode);
if (!task)
return -ESRCH;
- has_perms = has_pid_permissions(pid, task, HIDEPID_NO_ACCESS);
+ has_perms = has_pid_permissions(fs_info, task, HIDEPID_NO_ACCESS);
put_task_struct(task);
if (!has_perms) {
- if (pid->hide_pid == HIDEPID_INVISIBLE) {
+ if (fs_info->hide_pid == HIDEPID_INVISIBLE) {
/*
* Let's make getdents(), stat(), and open()
* consistent with each other. If a process
@@ -1897,7 +1897,7 @@ int pid_getattr(const struct path *path, struct kstat *stat,
u32 request_mask, unsigned int query_flags)
{
struct inode *inode = d_inode(path->dentry);
- struct pid_namespace *pid = proc_pid_ns(inode);
+ struct proc_fs_info *fs_info = proc_sb_info(inode->i_sb);
struct task_struct *task;
generic_fillattr(inode, stat);
@@ -1907,7 +1907,7 @@ int pid_getattr(const struct path *path, struct kstat *stat,
rcu_read_lock();
task = pid_task(proc_pid(inode), PIDTYPE_PID);
if (task) {
- if (!has_pid_permissions(pid, task, HIDEPID_INVISIBLE)) {
+ if (!has_pid_permissions(fs_info, task, HIDEPID_INVISIBLE)) {
rcu_read_unlock();
/*
* This doesn't prevent learning whether PID exists,
@@ -3402,7 +3402,7 @@ int proc_pid_readdir(struct file *file, struct dir_context *ctx)
unsigned int len;
cond_resched();
- if (!has_pid_permissions(ns, iter.task, HIDEPID_INVISIBLE))
+ if (!has_pid_permissions(fs_info, iter.task, HIDEPID_INVISIBLE))
continue;
len = snprintf(name, sizeof(name), "%u", iter.tgid);
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 6e4c6728338b..91fe4896fa85 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -168,12 +168,11 @@ void proc_invalidate_siblings_dcache(struct hlist_head *inodes, spinlock_t *lock
static int proc_show_options(struct seq_file *seq, struct dentry *root)
{
struct proc_fs_info *fs_info = proc_sb_info(root->d_sb);
- struct pid_namespace *pid = fs_info->pid_ns;
- if (!gid_eq(pid->pid_gid, GLOBAL_ROOT_GID))
- seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, pid->pid_gid));
- if (pid->hide_pid != HIDEPID_OFF)
- seq_printf(seq, ",hidepid=%u", pid->hide_pid);
+ if (!gid_eq(fs_info->pid_gid, GLOBAL_ROOT_GID))
+ seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
+ if (fs_info->hide_pid != HIDEPID_OFF)
+ seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
return 0;
}
diff --git a/fs/proc/root.c b/fs/proc/root.c
index b28adbb0b937..616e8976185c 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -85,9 +85,9 @@ static void proc_apply_options(struct super_block *s,
struct proc_fs_context *ctx = fc->fs_private;
if (ctx->mask & (1 << Opt_gid))
- pid_ns->pid_gid = make_kgid(user_ns, ctx->gid);
+ ctx->fs_info->pid_gid = make_kgid(user_ns, ctx->gid);
if (ctx->mask & (1 << Opt_hidepid))
- pid_ns->hide_pid = ctx->hidepid;
+ ctx->fs_info->hide_pid = ctx->hidepid;
}
static int proc_fill_super(struct super_block *s, struct fs_context *fc)
diff --git a/include/linux/pid_namespace.h b/include/linux/pid_namespace.h
index 4956e362e55e..028d7ba242c6 100644
--- a/include/linux/pid_namespace.h
+++ b/include/linux/pid_namespace.h
@@ -17,12 +17,6 @@
struct fs_pin;
-enum { /* definitions for pid_namespace's hide_pid field */
- HIDEPID_OFF = 0,
- HIDEPID_NO_ACCESS = 1,
- HIDEPID_INVISIBLE = 2,
-};
-
struct pid_namespace {
struct kref kref;
struct idr idr;
@@ -41,8 +35,6 @@ struct pid_namespace {
#endif
struct user_namespace *user_ns;
struct ucounts *ucounts;
- kgid_t pid_gid;
- int hide_pid;
int reboot; /* group exit code if this pidns was rebooted */
struct ns_common ns;
} __randomize_layout;
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 5920a4ecd71b..7d852dbca253 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -27,10 +27,19 @@ struct proc_ops {
unsigned long (*proc_get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
};
+/* definitions for hide_pid field */
+enum {
+ HIDEPID_OFF = 0,
+ HIDEPID_NO_ACCESS = 1,
+ HIDEPID_INVISIBLE = 2,
+};
+
struct proc_fs_info {
struct pid_namespace *pid_ns;
struct dentry *proc_self; /* For /proc/self */
struct dentry *proc_thread_self; /* For /proc/thread-self */
+ kgid_t pid_gid;
+ int hide_pid;
};
static inline struct proc_fs_info *proc_sb_info(struct super_block *sb)
--
2.25.2
Reviewed-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Alexey Gladkov <[email protected]>
---
fs/proc_namespace.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c
index 273ee82d8aa9..9a8b624bc3db 100644
--- a/fs/proc_namespace.c
+++ b/fs/proc_namespace.c
@@ -37,23 +37,23 @@ static __poll_t mounts_poll(struct file *file, poll_table *wait)
return res;
}
-struct proc_fs_info {
+struct proc_fs_opts {
int flag;
const char *str;
};
static int show_sb_opts(struct seq_file *m, struct super_block *sb)
{
- static const struct proc_fs_info fs_info[] = {
+ static const struct proc_fs_opts fs_opts[] = {
{ SB_SYNCHRONOUS, ",sync" },
{ SB_DIRSYNC, ",dirsync" },
{ SB_MANDLOCK, ",mand" },
{ SB_LAZYTIME, ",lazytime" },
{ 0, NULL }
};
- const struct proc_fs_info *fs_infop;
+ const struct proc_fs_opts *fs_infop;
- for (fs_infop = fs_info; fs_infop->flag; fs_infop++) {
+ for (fs_infop = fs_opts; fs_infop->flag; fs_infop++) {
if (sb->s_flags & fs_infop->flag)
seq_puts(m, fs_infop->str);
}
@@ -63,7 +63,7 @@ static int show_sb_opts(struct seq_file *m, struct super_block *sb)
static void show_mnt_opts(struct seq_file *m, struct vfsmount *mnt)
{
- static const struct proc_fs_info mnt_info[] = {
+ static const struct proc_fs_opts mnt_opts[] = {
{ MNT_NOSUID, ",nosuid" },
{ MNT_NODEV, ",nodev" },
{ MNT_NOEXEC, ",noexec" },
@@ -72,9 +72,9 @@ static void show_mnt_opts(struct seq_file *m, struct vfsmount *mnt)
{ MNT_RELATIME, ",relatime" },
{ 0, NULL }
};
- const struct proc_fs_info *fs_infop;
+ const struct proc_fs_opts *fs_infop;
- for (fs_infop = mnt_info; fs_infop->flag; fs_infop++) {
+ for (fs_infop = mnt_opts; fs_infop->flag; fs_infop++) {
if (mnt->mnt_flags & fs_infop->flag)
seq_puts(m, fs_infop->str);
}
--
2.25.2
This allows to hide all files and directories in the procfs that are not
related to tasks.
Reviewed-by: Alexey Dobriyan <[email protected]>
Signed-off-by: Alexey Gladkov <[email protected]>
---
fs/proc/generic.c | 9 +++++++++
fs/proc/inode.c | 6 ++++++
fs/proc/root.c | 33 +++++++++++++++++++++++++++++++++
include/linux/proc_fs.h | 7 +++++++
4 files changed, 55 insertions(+)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 3faed94e4b65..ee5b6482009c 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -269,6 +269,11 @@ struct dentry *proc_lookup_de(struct inode *dir, struct dentry *dentry,
struct dentry *proc_lookup(struct inode *dir, struct dentry *dentry,
unsigned int flags)
{
+ struct proc_fs_info *fs_info = proc_sb_info(dir->i_sb);
+
+ if (fs_info->pidonly == PROC_PIDONLY_ON)
+ return ERR_PTR(-ENOENT);
+
return proc_lookup_de(dir, dentry, PDE(dir));
}
@@ -325,6 +330,10 @@ int proc_readdir_de(struct file *file, struct dir_context *ctx,
int proc_readdir(struct file *file, struct dir_context *ctx)
{
struct inode *inode = file_inode(file);
+ struct proc_fs_info *fs_info = proc_sb_info(inode->i_sb);
+
+ if (fs_info->pidonly == PROC_PIDONLY_ON)
+ return 1;
return proc_readdir_de(file, ctx, PDE(inode));
}
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 91fe4896fa85..e6577ce6027b 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -173,6 +173,8 @@ static int proc_show_options(struct seq_file *seq, struct dentry *root)
seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
if (fs_info->hide_pid != HIDEPID_OFF)
seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
+ if (fs_info->pidonly != PROC_PIDONLY_OFF)
+ seq_printf(seq, ",subset=pid");
return 0;
}
@@ -393,12 +395,16 @@ proc_reg_get_unmapped_area(struct file *file, unsigned long orig_addr,
static int proc_reg_open(struct inode *inode, struct file *file)
{
+ struct proc_fs_info *fs_info = proc_sb_info(inode->i_sb);
struct proc_dir_entry *pde = PDE(inode);
int rv = 0;
typeof_member(struct proc_ops, proc_open) open;
typeof_member(struct proc_ops, proc_release) release;
struct pde_opener *pdeo;
+ if (fs_info->pidonly == PROC_PIDONLY_ON)
+ return -ENOENT;
+
/*
* Ensure that
* 1) PDE's ->release hook will be called no matter what
diff --git a/fs/proc/root.c b/fs/proc/root.c
index 62eae22403d2..dbcd96f07c7a 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -34,16 +34,19 @@ struct proc_fs_context {
unsigned int mask;
int hidepid;
int gid;
+ int pidonly;
};
enum proc_param {
Opt_gid,
Opt_hidepid,
+ Opt_subset,
};
static const struct fs_parameter_spec proc_fs_parameters[] = {
fsparam_u32("gid", Opt_gid),
fsparam_u32("hidepid", Opt_hidepid),
+ fsparam_string("subset", Opt_subset),
{}
};
@@ -55,6 +58,29 @@ static inline int valid_hidepid(unsigned int value)
value == HIDEPID_NOT_PTRACEABLE);
}
+static int proc_parse_subset_param(struct fs_context *fc, char *value)
+{
+ struct proc_fs_context *ctx = fc->fs_private;
+
+ while (value) {
+ char *ptr = strchr(value, ',');
+
+ if (ptr != NULL)
+ *ptr++ = '\0';
+
+ if (*value != '\0') {
+ if (!strcmp(value, "pid")) {
+ ctx->pidonly = PROC_PIDONLY_ON;
+ } else {
+ return invalf(fc, "proc: unsupported subset option - %s\n", value);
+ }
+ }
+ value = ptr;
+ }
+
+ return 0;
+}
+
static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
{
struct proc_fs_context *ctx = fc->fs_private;
@@ -76,6 +102,11 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
ctx->hidepid = result.uint_32;
break;
+ case Opt_subset:
+ if (proc_parse_subset_param(fc, param->string) < 0)
+ return -EINVAL;
+ break;
+
default:
return -EINVAL;
}
@@ -95,6 +126,8 @@ static void proc_apply_options(struct super_block *s,
ctx->fs_info->pid_gid = make_kgid(user_ns, ctx->gid);
if (ctx->mask & (1 << Opt_hidepid))
ctx->fs_info->hide_pid = ctx->hidepid;
+ if (ctx->mask & (1 << Opt_subset))
+ ctx->fs_info->pidonly = ctx->pidonly;
}
static int proc_fill_super(struct super_block *s, struct fs_context *fc)
diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
index 21d19353fdc7..afd38cae2339 100644
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -35,12 +35,19 @@ enum {
HIDEPID_NOT_PTRACEABLE = 4, /* Limit pids to only ptraceable pids */
};
+/* definitions for proc mount option pidonly */
+enum {
+ PROC_PIDONLY_OFF = 0,
+ PROC_PIDONLY_ON = 1,
+};
+
struct proc_fs_info {
struct pid_namespace *pid_ns;
struct dentry *proc_self; /* For /proc/self */
struct dentry *proc_thread_self; /* For /proc/thread-self */
kgid_t pid_gid;
int hide_pid;
+ int pidonly;
};
static inline struct proc_fs_info *proc_sb_info(struct super_block *sb)
--
2.25.2
On Fri, Mar 27, 2020 at 06:23:30PM +0100, Alexey Gladkov wrote:
> The hidepid parameter values are becoming more and more and it becomes
> difficult to remember what each new magic number means.
>
> Suggested-by: Andy Lutomirski <[email protected]>
> Reviewed-by: Alexey Dobriyan <[email protected]>
> Signed-off-by: Alexey Gladkov <[email protected]>
> ---
> Documentation/filesystems/proc.txt | 52 +++++++++++++++---------------
> fs/proc/inode.c | 13 +++++++-
> fs/proc/root.c | 36 +++++++++++++++++++--
> 3 files changed, 71 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index bd0e0ab85048..af47672cb2cb 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -2025,28 +2025,28 @@ The following mount options are supported:
> 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).
> -
> -hidepid=1 means users may not access any /proc/<pid>/ directories but their
> -own. Sensitive files like cmdline, sched*, status are now protected against
> -other users. This makes it impossible to learn whether any user runs
> -specific program (given the program doesn't reveal itself by its behaviour).
> -As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
> -poorly written programs passing sensitive information via program arguments are
> -now protected against local eavesdroppers.
> -
> -hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
> -users. It doesn't mean that it hides a fact whether a process with a specific
> -pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
> -but it hides process' uid and gid, which may be learned by stat()'ing
> -/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
> -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.
> +hidepid=off or hidepid=0 means classic mode - everybody may access all
> +/proc/<pid>/ directories (default).
> +
> +hidepid=noaccess or hidepid=1 means users may not access any /proc/<pid>/
> +directories but their own. Sensitive files like cmdline, sched*, status are now
> +protected against other users. This makes it impossible to learn whether any
> +user runs specific program (given the program doesn't reveal itself by its
> +behaviour). As an additional bonus, as /proc/<pid>/cmdline is unaccessible for
> +other users, poorly written programs passing sensitive information via program
> +arguments are now protected against local eavesdroppers.
> +
> +hidepid=invisible or hidepid=2 means hidepid=noaccess plus all /proc/<pid>/ will
> +be fully invisible to other users. It doesn't mean that it hides a fact whether
> +a process with a specific pid value exists (it can be learned by other means,
> +e.g. by "kill -0 $PID"), but it hides process' uid and gid, which may be learned
> +by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task
> +of gathering 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=ptraceable or hidepid=4 means that procfs should only contain
> +/proc/<pid>/ directories that the caller can ptrace.
>
> gid= defines a group authorized to learn processes information otherwise
> prohibited by hidepid=. If you use some daemon like identd which needs to learn
> @@ -2093,8 +2093,8 @@ creates a new procfs instance. Mount options affect own procfs instance.
> It means that it became possible to have several procfs instances
> displaying tasks with different filtering options in one pid namespace.
>
> -# mount -o hidepid=2 -t proc proc /proc
> -# mount -o hidepid=1 -t proc proc /tmp/proc
> +# mount -o hidepid=invisible -t proc proc /proc
> +# mount -o hidepid=noaccess -t proc proc /tmp/proc
> # grep ^proc /proc/mounts
> -proc /proc proc rw,relatime,hidepid=2 0 0
> -proc /tmp/proc proc rw,relatime,hidepid=1 0 0
> +proc /proc proc rw,relatime,hidepid=invisible 0 0
> +proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> index e6577ce6027b..f01fb4bed75c 100644
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -165,6 +165,17 @@ void proc_invalidate_siblings_dcache(struct hlist_head *inodes, spinlock_t *lock
> deactivate_super(old_sb);
> }
>
> +static inline const char *hidepid2str(int v)
> +{
> + switch (v) {
> + case HIDEPID_OFF: return "off";
> + case HIDEPID_NO_ACCESS: return "noaccess";
> + case HIDEPID_INVISIBLE: return "invisible";
> + case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
> + }
> + BUG();
Please don't use BUG()[1]. Add a default case with a warn and return
"unknown":
switch (v) {
case HIDEPID_OFF: return "off";
case HIDEPID_NO_ACCESS: return "noaccess";
case HIDEPID_INVISIBLE: return "invisible";
case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
default:
WARN_ON_ONCE("bad hide_pid value: %d\n", v);
return "unknown";
}
[1] https://lore.kernel.org/lkml/202003141524.59C619B51A@keescook/
> +}
> +
> static int proc_show_options(struct seq_file *seq, struct dentry *root)
> {
> struct proc_fs_info *fs_info = proc_sb_info(root->d_sb);
> @@ -172,7 +183,7 @@ static int proc_show_options(struct seq_file *seq, struct dentry *root)
> if (!gid_eq(fs_info->pid_gid, GLOBAL_ROOT_GID))
> seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
> if (fs_info->hide_pid != HIDEPID_OFF)
> - seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
> + seq_printf(seq, ",hidepid=%s", hidepid2str(fs_info->hide_pid));
> if (fs_info->pidonly != PROC_PIDONLY_OFF)
> seq_printf(seq, ",subset=pid");
>
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index dbcd96f07c7a..ba782d6e6197 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -45,7 +45,7 @@ enum proc_param {
>
> static const struct fs_parameter_spec proc_fs_parameters[] = {
> fsparam_u32("gid", Opt_gid),
> - fsparam_u32("hidepid", Opt_hidepid),
> + fsparam_string("hidepid", Opt_hidepid),
> fsparam_string("subset", Opt_subset),
> {}
> };
> @@ -58,6 +58,35 @@ static inline int valid_hidepid(unsigned int value)
> value == HIDEPID_NOT_PTRACEABLE);
> }
>
> +static int proc_parse_hidepid_param(struct fs_context *fc, struct fs_parameter *param)
> +{
> + struct proc_fs_context *ctx = fc->fs_private;
> + struct fs_parameter_spec hidepid_u32_spec = fsparam_u32("hidepid", Opt_hidepid);
> + struct fs_parse_result result;
> + int base = (unsigned long)hidepid_u32_spec.data;
> +
> + if (param->type != fs_value_is_string)
> + return invalf(fc, "proc: unexpected type of hidepid value\n");
> +
> + if (!kstrtouint(param->string, base, &result.uint_32)) {
> + ctx->hidepid = result.uint_32;
This need to bounds-check the value with a call to valid_hidepid(), yes?
> + return 0;
> + }
> +
> + if (!strcmp(param->string, "off"))
> + ctx->hidepid = HIDEPID_OFF;
> + else if (!strcmp(param->string, "noaccess"))
> + ctx->hidepid = HIDEPID_NO_ACCESS;
> + else if (!strcmp(param->string, "invisible"))
> + ctx->hidepid = HIDEPID_INVISIBLE;
> + else if (!strcmp(param->string, "ptraceable"))
> + ctx->hidepid = HIDEPID_NOT_PTRACEABLE;
> + else
> + return invalf(fc, "proc: unknown value of hidepid - %s\n", param->string);
> +
> + return 0;
> +}
> +
> static int proc_parse_subset_param(struct fs_context *fc, char *value)
> {
> struct proc_fs_context *ctx = fc->fs_private;
> @@ -97,9 +126,10 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
> break;
>
> case Opt_hidepid:
> - if (!valid_hidepid(result.uint_32))
> + if (proc_parse_hidepid_param(fc, param))
> + return -EINVAL;
> + if (!valid_hidepid(ctx->hidepid))
> return invalf(fc, "proc: unknown value of hidepid.\n");
> - ctx->hidepid = result.uint_32;
> break;
>
> case Opt_subset:
> --
> 2.25.2
>
--
Kees Cook
On Sat, Mar 28, 2020 at 01:28:28PM -0700, Kees Cook wrote:
> On Fri, Mar 27, 2020 at 06:23:30PM +0100, Alexey Gladkov wrote:
> > The hidepid parameter values are becoming more and more and it becomes
> > difficult to remember what each new magic number means.
> >
> > Suggested-by: Andy Lutomirski <[email protected]>
> > Reviewed-by: Alexey Dobriyan <[email protected]>
> > Signed-off-by: Alexey Gladkov <[email protected]>
> > ---
> > Documentation/filesystems/proc.txt | 52 +++++++++++++++---------------
> > fs/proc/inode.c | 13 +++++++-
> > fs/proc/root.c | 36 +++++++++++++++++++--
> > 3 files changed, 71 insertions(+), 30 deletions(-)
> >
> > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> > index bd0e0ab85048..af47672cb2cb 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -2025,28 +2025,28 @@ The following mount options are supported:
> > 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).
> > -
> > -hidepid=1 means users may not access any /proc/<pid>/ directories but their
> > -own. Sensitive files like cmdline, sched*, status are now protected against
> > -other users. This makes it impossible to learn whether any user runs
> > -specific program (given the program doesn't reveal itself by its behaviour).
> > -As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
> > -poorly written programs passing sensitive information via program arguments are
> > -now protected against local eavesdroppers.
> > -
> > -hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
> > -users. It doesn't mean that it hides a fact whether a process with a specific
> > -pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
> > -but it hides process' uid and gid, which may be learned by stat()'ing
> > -/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
> > -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.
> > +hidepid=off or hidepid=0 means classic mode - everybody may access all
> > +/proc/<pid>/ directories (default).
> > +
> > +hidepid=noaccess or hidepid=1 means users may not access any /proc/<pid>/
> > +directories but their own. Sensitive files like cmdline, sched*, status are now
> > +protected against other users. This makes it impossible to learn whether any
> > +user runs specific program (given the program doesn't reveal itself by its
> > +behaviour). As an additional bonus, as /proc/<pid>/cmdline is unaccessible for
> > +other users, poorly written programs passing sensitive information via program
> > +arguments are now protected against local eavesdroppers.
> > +
> > +hidepid=invisible or hidepid=2 means hidepid=noaccess plus all /proc/<pid>/ will
> > +be fully invisible to other users. It doesn't mean that it hides a fact whether
> > +a process with a specific pid value exists (it can be learned by other means,
> > +e.g. by "kill -0 $PID"), but it hides process' uid and gid, which may be learned
> > +by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task
> > +of gathering 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=ptraceable or hidepid=4 means that procfs should only contain
> > +/proc/<pid>/ directories that the caller can ptrace.
> >
> > gid= defines a group authorized to learn processes information otherwise
> > prohibited by hidepid=. If you use some daemon like identd which needs to learn
> > @@ -2093,8 +2093,8 @@ creates a new procfs instance. Mount options affect own procfs instance.
> > It means that it became possible to have several procfs instances
> > displaying tasks with different filtering options in one pid namespace.
> >
> > -# mount -o hidepid=2 -t proc proc /proc
> > -# mount -o hidepid=1 -t proc proc /tmp/proc
> > +# mount -o hidepid=invisible -t proc proc /proc
> > +# mount -o hidepid=noaccess -t proc proc /tmp/proc
> > # grep ^proc /proc/mounts
> > -proc /proc proc rw,relatime,hidepid=2 0 0
> > -proc /tmp/proc proc rw,relatime,hidepid=1 0 0
> > +proc /proc proc rw,relatime,hidepid=invisible 0 0
> > +proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
> > diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> > index e6577ce6027b..f01fb4bed75c 100644
> > --- a/fs/proc/inode.c
> > +++ b/fs/proc/inode.c
> > @@ -165,6 +165,17 @@ void proc_invalidate_siblings_dcache(struct hlist_head *inodes, spinlock_t *lock
> > deactivate_super(old_sb);
> > }
> >
> > +static inline const char *hidepid2str(int v)
> > +{
> > + switch (v) {
> > + case HIDEPID_OFF: return "off";
> > + case HIDEPID_NO_ACCESS: return "noaccess";
> > + case HIDEPID_INVISIBLE: return "invisible";
> > + case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
> > + }
> > + BUG();
>
> Please don't use BUG()[1]. Add a default case with a warn and return
> "unknown":
>
> switch (v) {
> case HIDEPID_OFF: return "off";
> case HIDEPID_NO_ACCESS: return "noaccess";
> case HIDEPID_INVISIBLE: return "invisible";
> case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
> default:
> WARN_ON_ONCE("bad hide_pid value: %d\n", v);
> return "unknown";
> }
>
> [1] https://lore.kernel.org/lkml/202003141524.59C619B51A@keescook/
Make sense. I will change it.
> > +}
> > +
> > static int proc_show_options(struct seq_file *seq, struct dentry *root)
> > {
> > struct proc_fs_info *fs_info = proc_sb_info(root->d_sb);
> > @@ -172,7 +183,7 @@ static int proc_show_options(struct seq_file *seq, struct dentry *root)
> > if (!gid_eq(fs_info->pid_gid, GLOBAL_ROOT_GID))
> > seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
> > if (fs_info->hide_pid != HIDEPID_OFF)
> > - seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
> > + seq_printf(seq, ",hidepid=%s", hidepid2str(fs_info->hide_pid));
> > if (fs_info->pidonly != PROC_PIDONLY_OFF)
> > seq_printf(seq, ",subset=pid");
> >
> > diff --git a/fs/proc/root.c b/fs/proc/root.c
> > index dbcd96f07c7a..ba782d6e6197 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -45,7 +45,7 @@ enum proc_param {
> >
> > static const struct fs_parameter_spec proc_fs_parameters[] = {
> > fsparam_u32("gid", Opt_gid),
> > - fsparam_u32("hidepid", Opt_hidepid),
> > + fsparam_string("hidepid", Opt_hidepid),
> > fsparam_string("subset", Opt_subset),
> > {}
> > };
> > @@ -58,6 +58,35 @@ static inline int valid_hidepid(unsigned int value)
> > value == HIDEPID_NOT_PTRACEABLE);
> > }
> >
> > +static int proc_parse_hidepid_param(struct fs_context *fc, struct fs_parameter *param)
> > +{
> > + struct proc_fs_context *ctx = fc->fs_private;
> > + struct fs_parameter_spec hidepid_u32_spec = fsparam_u32("hidepid", Opt_hidepid);
> > + struct fs_parse_result result;
> > + int base = (unsigned long)hidepid_u32_spec.data;
> > +
> > + if (param->type != fs_value_is_string)
> > + return invalf(fc, "proc: unexpected type of hidepid value\n");
> > +
> > + if (!kstrtouint(param->string, base, &result.uint_32)) {
> > + ctx->hidepid = result.uint_32;
>
> This need to bounds-check the value with a call to valid_hidepid(), yes?
The kstrtouint returns 0 on success and -ERANGE on overflow [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kstrtox.c#n217
> > + return 0;
> > + }
> > +
> > + if (!strcmp(param->string, "off"))
> > + ctx->hidepid = HIDEPID_OFF;
> > + else if (!strcmp(param->string, "noaccess"))
> > + ctx->hidepid = HIDEPID_NO_ACCESS;
> > + else if (!strcmp(param->string, "invisible"))
> > + ctx->hidepid = HIDEPID_INVISIBLE;
> > + else if (!strcmp(param->string, "ptraceable"))
> > + ctx->hidepid = HIDEPID_NOT_PTRACEABLE;
> > + else
> > + return invalf(fc, "proc: unknown value of hidepid - %s\n", param->string);
> > +
> > + return 0;
> > +}
> > +
> > static int proc_parse_subset_param(struct fs_context *fc, char *value)
> > {
> > struct proc_fs_context *ctx = fc->fs_private;
> > @@ -97,9 +126,10 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
> > break;
> >
> > case Opt_hidepid:
> > - if (!valid_hidepid(result.uint_32))
> > + if (proc_parse_hidepid_param(fc, param))
> > + return -EINVAL;
> > + if (!valid_hidepid(ctx->hidepid))
> > return invalf(fc, "proc: unknown value of hidepid.\n");
> > - ctx->hidepid = result.uint_32;
> > break;
> >
> > case Opt_subset:
> > --
> > 2.25.2
> >
>
> --
> Kees Cook
>
--
Rgrds, legion
On Sat, Mar 28, 2020 at 10:14:53PM +0100, Alexey Gladkov wrote:
> On Sat, Mar 28, 2020 at 01:28:28PM -0700, Kees Cook wrote:
> > On Fri, Mar 27, 2020 at 06:23:30PM +0100, Alexey Gladkov wrote:
> > > [...]
> > > + if (!kstrtouint(param->string, base, &result.uint_32)) {
> > > + ctx->hidepid = result.uint_32;
> >
> > This need to bounds-check the value with a call to valid_hidepid(), yes?
>
> The kstrtouint returns 0 on success and -ERANGE on overflow [1].
No, I mean, hidepid cannot be just any uint32 value. It must be in the
enum. Is that checked somewhere else? It looked like the call to
valid_hidepid() was removed.
--
Kees Cook
On Sat, Mar 28, 2020 at 02:52:55PM -0700, Kees Cook wrote:
> On Sat, Mar 28, 2020 at 10:14:53PM +0100, Alexey Gladkov wrote:
> > On Sat, Mar 28, 2020 at 01:28:28PM -0700, Kees Cook wrote:
> > > On Fri, Mar 27, 2020 at 06:23:30PM +0100, Alexey Gladkov wrote:
> > > > [...]
> > > > + if (!kstrtouint(param->string, base, &result.uint_32)) {
> > > > + ctx->hidepid = result.uint_32;
> > >
> > > This need to bounds-check the value with a call to valid_hidepid(), yes?
> >
> > The kstrtouint returns 0 on success and -ERANGE on overflow [1].
>
> No, I mean, hidepid cannot be just any uint32 value. It must be in the
> enum. Is that checked somewhere else? It looked like the call to
> valid_hidepid() was removed.
The valid_hidepid() is called after parsing the hidepid parameter value.
Yes, it can be called inside this condition.
--
Rgrds, legion
The hidepid parameter values are becoming more and more and it becomes
difficult to remember what each new magic number means.
Suggested-by: Andy Lutomirski <[email protected]>
Signed-off-by: Alexey Gladkov <[email protected]>
---
Documentation/filesystems/proc.txt | 52 +++++++++++++++---------------
fs/proc/inode.c | 15 ++++++++-
fs/proc/root.c | 36 +++++++++++++++++++--
3 files changed, 73 insertions(+), 30 deletions(-)
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index bd0e0ab85048..af47672cb2cb 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -2025,28 +2025,28 @@ The following mount options are supported:
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).
-
-hidepid=1 means users may not access any /proc/<pid>/ directories but their
-own. Sensitive files like cmdline, sched*, status are now protected against
-other users. This makes it impossible to learn whether any user runs
-specific program (given the program doesn't reveal itself by its behaviour).
-As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
-poorly written programs passing sensitive information via program arguments are
-now protected against local eavesdroppers.
-
-hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
-users. It doesn't mean that it hides a fact whether a process with a specific
-pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
-but it hides process' uid and gid, which may be learned by stat()'ing
-/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
-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.
+hidepid=off or hidepid=0 means classic mode - everybody may access all
+/proc/<pid>/ directories (default).
+
+hidepid=noaccess or hidepid=1 means users may not access any /proc/<pid>/
+directories but their own. Sensitive files like cmdline, sched*, status are now
+protected against other users. This makes it impossible to learn whether any
+user runs specific program (given the program doesn't reveal itself by its
+behaviour). As an additional bonus, as /proc/<pid>/cmdline is unaccessible for
+other users, poorly written programs passing sensitive information via program
+arguments are now protected against local eavesdroppers.
+
+hidepid=invisible or hidepid=2 means hidepid=noaccess plus all /proc/<pid>/ will
+be fully invisible to other users. It doesn't mean that it hides a fact whether
+a process with a specific pid value exists (it can be learned by other means,
+e.g. by "kill -0 $PID"), but it hides process' uid and gid, which may be learned
+by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task
+of gathering 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=ptraceable or hidepid=4 means that procfs should only contain
+/proc/<pid>/ directories that the caller can ptrace.
gid= defines a group authorized to learn processes information otherwise
prohibited by hidepid=. If you use some daemon like identd which needs to learn
@@ -2093,8 +2093,8 @@ creates a new procfs instance. Mount options affect own procfs instance.
It means that it became possible to have several procfs instances
displaying tasks with different filtering options in one pid namespace.
-# mount -o hidepid=2 -t proc proc /proc
-# mount -o hidepid=1 -t proc proc /tmp/proc
+# mount -o hidepid=invisible -t proc proc /proc
+# mount -o hidepid=noaccess -t proc proc /tmp/proc
# grep ^proc /proc/mounts
-proc /proc proc rw,relatime,hidepid=2 0 0
-proc /tmp/proc proc rw,relatime,hidepid=1 0 0
+proc /proc proc rw,relatime,hidepid=invisible 0 0
+proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index e6577ce6027b..d38a9e592352 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -24,6 +24,7 @@
#include <linux/seq_file.h>
#include <linux/slab.h>
#include <linux/mount.h>
+#include <linux/bug.h>
#include <linux/uaccess.h>
@@ -165,6 +166,18 @@ void proc_invalidate_siblings_dcache(struct hlist_head *inodes, spinlock_t *lock
deactivate_super(old_sb);
}
+static inline const char *hidepid2str(int v)
+{
+ switch (v) {
+ case HIDEPID_OFF: return "off";
+ case HIDEPID_NO_ACCESS: return "noaccess";
+ case HIDEPID_INVISIBLE: return "invisible";
+ case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
+ }
+ WARN_ONCE(1, "bad hide_pid value: %d\n", v);
+ return "unknown";
+}
+
static int proc_show_options(struct seq_file *seq, struct dentry *root)
{
struct proc_fs_info *fs_info = proc_sb_info(root->d_sb);
@@ -172,7 +185,7 @@ static int proc_show_options(struct seq_file *seq, struct dentry *root)
if (!gid_eq(fs_info->pid_gid, GLOBAL_ROOT_GID))
seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
if (fs_info->hide_pid != HIDEPID_OFF)
- seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
+ seq_printf(seq, ",hidepid=%s", hidepid2str(fs_info->hide_pid));
if (fs_info->pidonly != PROC_PIDONLY_OFF)
seq_printf(seq, ",subset=pid");
diff --git a/fs/proc/root.c b/fs/proc/root.c
index dbcd96f07c7a..ba782d6e6197 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -45,7 +45,7 @@ enum proc_param {
static const struct fs_parameter_spec proc_fs_parameters[] = {
fsparam_u32("gid", Opt_gid),
- fsparam_u32("hidepid", Opt_hidepid),
+ fsparam_string("hidepid", Opt_hidepid),
fsparam_string("subset", Opt_subset),
{}
};
@@ -58,6 +58,35 @@ static inline int valid_hidepid(unsigned int value)
value == HIDEPID_NOT_PTRACEABLE);
}
+static int proc_parse_hidepid_param(struct fs_context *fc, struct fs_parameter *param)
+{
+ struct proc_fs_context *ctx = fc->fs_private;
+ struct fs_parameter_spec hidepid_u32_spec = fsparam_u32("hidepid", Opt_hidepid);
+ struct fs_parse_result result;
+ int base = (unsigned long)hidepid_u32_spec.data;
+
+ if (param->type != fs_value_is_string)
+ return invalf(fc, "proc: unexpected type of hidepid value\n");
+
+ if (!kstrtouint(param->string, base, &result.uint_32)) {
+ ctx->hidepid = result.uint_32;
+ return 0;
+ }
+
+ if (!strcmp(param->string, "off"))
+ ctx->hidepid = HIDEPID_OFF;
+ else if (!strcmp(param->string, "noaccess"))
+ ctx->hidepid = HIDEPID_NO_ACCESS;
+ else if (!strcmp(param->string, "invisible"))
+ ctx->hidepid = HIDEPID_INVISIBLE;
+ else if (!strcmp(param->string, "ptraceable"))
+ ctx->hidepid = HIDEPID_NOT_PTRACEABLE;
+ else
+ return invalf(fc, "proc: unknown value of hidepid - %s\n", param->string);
+
+ return 0;
+}
+
static int proc_parse_subset_param(struct fs_context *fc, char *value)
{
struct proc_fs_context *ctx = fc->fs_private;
@@ -97,9 +126,10 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
break;
case Opt_hidepid:
- if (!valid_hidepid(result.uint_32))
+ if (proc_parse_hidepid_param(fc, param))
+ return -EINVAL;
+ if (!valid_hidepid(ctx->hidepid))
return invalf(fc, "proc: unknown value of hidepid.\n");
- ctx->hidepid = result.uint_32;
break;
case Opt_subset:
--
2.25.2
On Mon, Mar 30, 2020 at 01:12:35PM +0200, Alexey Gladkov wrote:
> The hidepid parameter values are becoming more and more and it becomes
> difficult to remember what each new magic number means.
>
> Suggested-by: Andy Lutomirski <[email protected]>
> Signed-off-by: Alexey Gladkov <[email protected]>
> ---
> Documentation/filesystems/proc.txt | 52 +++++++++++++++---------------
> fs/proc/inode.c | 15 ++++++++-
> fs/proc/root.c | 36 +++++++++++++++++++--
> 3 files changed, 73 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index bd0e0ab85048..af47672cb2cb 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -2025,28 +2025,28 @@ The following mount options are supported:
> 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).
> -
> -hidepid=1 means users may not access any /proc/<pid>/ directories but their
> -own. Sensitive files like cmdline, sched*, status are now protected against
> -other users. This makes it impossible to learn whether any user runs
> -specific program (given the program doesn't reveal itself by its behaviour).
> -As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
> -poorly written programs passing sensitive information via program arguments are
> -now protected against local eavesdroppers.
> -
> -hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
> -users. It doesn't mean that it hides a fact whether a process with a specific
> -pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
> -but it hides process' uid and gid, which may be learned by stat()'ing
> -/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
> -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.
> +hidepid=off or hidepid=0 means classic mode - everybody may access all
> +/proc/<pid>/ directories (default).
> +
> +hidepid=noaccess or hidepid=1 means users may not access any /proc/<pid>/
> +directories but their own. Sensitive files like cmdline, sched*, status are now
> +protected against other users. This makes it impossible to learn whether any
> +user runs specific program (given the program doesn't reveal itself by its
> +behaviour). As an additional bonus, as /proc/<pid>/cmdline is unaccessible for
> +other users, poorly written programs passing sensitive information via program
> +arguments are now protected against local eavesdroppers.
> +
> +hidepid=invisible or hidepid=2 means hidepid=noaccess plus all /proc/<pid>/ will
> +be fully invisible to other users. It doesn't mean that it hides a fact whether
> +a process with a specific pid value exists (it can be learned by other means,
> +e.g. by "kill -0 $PID"), but it hides process' uid and gid, which may be learned
> +by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an intruder's task
> +of gathering 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=ptraceable or hidepid=4 means that procfs should only contain
> +/proc/<pid>/ directories that the caller can ptrace.
>
> gid= defines a group authorized to learn processes information otherwise
> prohibited by hidepid=. If you use some daemon like identd which needs to learn
> @@ -2093,8 +2093,8 @@ creates a new procfs instance. Mount options affect own procfs instance.
> It means that it became possible to have several procfs instances
> displaying tasks with different filtering options in one pid namespace.
>
> -# mount -o hidepid=2 -t proc proc /proc
> -# mount -o hidepid=1 -t proc proc /tmp/proc
> +# mount -o hidepid=invisible -t proc proc /proc
> +# mount -o hidepid=noaccess -t proc proc /tmp/proc
> # grep ^proc /proc/mounts
> -proc /proc proc rw,relatime,hidepid=2 0 0
> -proc /tmp/proc proc rw,relatime,hidepid=1 0 0
> +proc /proc proc rw,relatime,hidepid=invisible 0 0
> +proc /tmp/proc proc rw,relatime,hidepid=noaccess 0 0
> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> index e6577ce6027b..d38a9e592352 100644
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -24,6 +24,7 @@
> #include <linux/seq_file.h>
> #include <linux/slab.h>
> #include <linux/mount.h>
> +#include <linux/bug.h>
>
> #include <linux/uaccess.h>
>
> @@ -165,6 +166,18 @@ void proc_invalidate_siblings_dcache(struct hlist_head *inodes, spinlock_t *lock
> deactivate_super(old_sb);
> }
>
> +static inline const char *hidepid2str(int v)
> +{
> + switch (v) {
> + case HIDEPID_OFF: return "off";
> + case HIDEPID_NO_ACCESS: return "noaccess";
> + case HIDEPID_INVISIBLE: return "invisible";
> + case HIDEPID_NOT_PTRACEABLE: return "ptraceable";
> + }
> + WARN_ONCE(1, "bad hide_pid value: %d\n", v);
> + return "unknown";
> +}
> +
> static int proc_show_options(struct seq_file *seq, struct dentry *root)
> {
> struct proc_fs_info *fs_info = proc_sb_info(root->d_sb);
> @@ -172,7 +185,7 @@ static int proc_show_options(struct seq_file *seq, struct dentry *root)
> if (!gid_eq(fs_info->pid_gid, GLOBAL_ROOT_GID))
> seq_printf(seq, ",gid=%u", from_kgid_munged(&init_user_ns, fs_info->pid_gid));
> if (fs_info->hide_pid != HIDEPID_OFF)
> - seq_printf(seq, ",hidepid=%u", fs_info->hide_pid);
> + seq_printf(seq, ",hidepid=%s", hidepid2str(fs_info->hide_pid));
> if (fs_info->pidonly != PROC_PIDONLY_OFF)
> seq_printf(seq, ",subset=pid");
>
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index dbcd96f07c7a..ba782d6e6197 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -45,7 +45,7 @@ enum proc_param {
>
> static const struct fs_parameter_spec proc_fs_parameters[] = {
> fsparam_u32("gid", Opt_gid),
> - fsparam_u32("hidepid", Opt_hidepid),
> + fsparam_string("hidepid", Opt_hidepid),
> fsparam_string("subset", Opt_subset),
> {}
> };
> @@ -58,6 +58,35 @@ static inline int valid_hidepid(unsigned int value)
> value == HIDEPID_NOT_PTRACEABLE);
> }
>
> +static int proc_parse_hidepid_param(struct fs_context *fc, struct fs_parameter *param)
> +{
> + struct proc_fs_context *ctx = fc->fs_private;
> + struct fs_parameter_spec hidepid_u32_spec = fsparam_u32("hidepid", Opt_hidepid);
> + struct fs_parse_result result;
> + int base = (unsigned long)hidepid_u32_spec.data;
> +
> + if (param->type != fs_value_is_string)
> + return invalf(fc, "proc: unexpected type of hidepid value\n");
> +
> + if (!kstrtouint(param->string, base, &result.uint_32)) {
> + ctx->hidepid = result.uint_32;
If it were me, I'd put this valid_hidepid() test inside here, then the
parsing really is entirely done by this function. Otherwise, the
validation is spread into proc_parse_param() which seems weird.
But either way:
Reviewed-by: Kees Cook <[email protected]>
-Kees
> + return 0;
> + }
> +
> + if (!strcmp(param->string, "off"))
> + ctx->hidepid = HIDEPID_OFF;
> + else if (!strcmp(param->string, "noaccess"))
> + ctx->hidepid = HIDEPID_NO_ACCESS;
> + else if (!strcmp(param->string, "invisible"))
> + ctx->hidepid = HIDEPID_INVISIBLE;
> + else if (!strcmp(param->string, "ptraceable"))
> + ctx->hidepid = HIDEPID_NOT_PTRACEABLE;
> + else
> + return invalf(fc, "proc: unknown value of hidepid - %s\n", param->string);
> +
> + return 0;
> +}
> +
> static int proc_parse_subset_param(struct fs_context *fc, char *value)
> {
> struct proc_fs_context *ctx = fc->fs_private;
> @@ -97,9 +126,10 @@ static int proc_parse_param(struct fs_context *fc, struct fs_parameter *param)
> break;
>
> case Opt_hidepid:
> - if (!valid_hidepid(result.uint_32))
> + if (proc_parse_hidepid_param(fc, param))
> + return -EINVAL;
> + if (!valid_hidepid(ctx->hidepid))
> return invalf(fc, "proc: unknown value of hidepid.\n");
> - ctx->hidepid = result.uint_32;
> break;
>
> case Opt_subset:
> --
> 2.25.2
>
--
Kees Cook
On Mon, Mar 30, 2020 at 1:13 PM Alexey Gladkov <[email protected]> wrote:
> The hidepid parameter values are becoming more and more and it becomes
> difficult to remember what each new magic number means.
nit: subject line says "hidehid"
Alexey Gladkov <[email protected]> writes:
> The hidepid parameter values are becoming more and more and it becomes
> difficult to remember what each new magic number means.
In principle I like this change. In practice I think you have just
broken ABI compatiblity with the new mount ABI.
In particular the following line seems broken.
> diff --git a/fs/proc/root.c b/fs/proc/root.c
> index dbcd96f07c7a..ba782d6e6197 100644
> --- a/fs/proc/root.c
> +++ b/fs/proc/root.c
> @@ -45,7 +45,7 @@ enum proc_param {
>
> static const struct fs_parameter_spec proc_fs_parameters[] = {
> fsparam_u32("gid", Opt_gid),
> - fsparam_u32("hidepid", Opt_hidepid),
> + fsparam_string("hidepid", Opt_hidepid),
> fsparam_string("subset", Opt_subset),
> {}
> };
As I read fs_parser.c fs_param_is_u32 handles string inputs and turns them
into numbers, and it handles binary numbers. However fs_param_is_string
appears to only handle strings. It appears to have not capacity to turn
raw binary numbers into strings.
So I think we probably need to fix fs_param_is_string to raw binary
numbers before we can safely make this change to fs/proc/root.c
David am I reading the fs_parser.c code correctly? If I am are you ok
with a change like the above?
Eric
On Thu, Apr 02, 2020 at 11:05:21AM -0500, Eric W. Biederman wrote:
> Alexey Gladkov <[email protected]> writes:
>
> > The hidepid parameter values are becoming more and more and it becomes
> > difficult to remember what each new magic number means.
>
> In principle I like this change. In practice I think you have just
> broken ABI compatiblity with the new mount ABI.
>
> In particular the following line seems broken.
>
> > diff --git a/fs/proc/root.c b/fs/proc/root.c
> > index dbcd96f07c7a..ba782d6e6197 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -45,7 +45,7 @@ enum proc_param {
> >
> > static const struct fs_parameter_spec proc_fs_parameters[] = {
> > fsparam_u32("gid", Opt_gid),
> > - fsparam_u32("hidepid", Opt_hidepid),
> > + fsparam_string("hidepid", Opt_hidepid),
> > fsparam_string("subset", Opt_subset),
> > {}
> > };
>
> As I read fs_parser.c fs_param_is_u32 handles string inputs and turns them
> into numbers, and it handles binary numbers. However fs_param_is_string
> appears to only handle strings. It appears to have not capacity to turn
> raw binary numbers into strings.
I use result only with hidepid_u32_spec and nobody modifies param->string.
I do not use internal functions here.
I don’t follow how a raw number can get here ?
> So I think we probably need to fix fs_param_is_string to raw binary
> numbers before we can safely make this change to fs/proc/root.c
>
> David am I reading the fs_parser.c code correctly? If I am are you ok
> with a change like the above?
>
> Eric
>
--
Rgrds, legion
Overall this patchset looks good.
I have found a couple of nits. The biggest is the potential ABI change.
I would be surprised if someone is using the new mount ABI so changing
that may not be a regression. But it is worth a close look.
One way or another I will ensure we get this in linux-next after the
merge window closes.
Eric
Alexey Gladkov <[email protected]> writes:
> On Thu, Apr 02, 2020 at 11:05:21AM -0500, Eric W. Biederman wrote:
>> Alexey Gladkov <[email protected]> writes:
>>
>> > The hidepid parameter values are becoming more and more and it becomes
>> > difficult to remember what each new magic number means.
>>
>> In principle I like this change. In practice I think you have just
>> broken ABI compatiblity with the new mount ABI.
>>
>> In particular the following line seems broken.
>>
>> > diff --git a/fs/proc/root.c b/fs/proc/root.c
>> > index dbcd96f07c7a..ba782d6e6197 100644
>> > --- a/fs/proc/root.c
>> > +++ b/fs/proc/root.c
>> > @@ -45,7 +45,7 @@ enum proc_param {
>> >
>> > static const struct fs_parameter_spec proc_fs_parameters[] = {
>> > fsparam_u32("gid", Opt_gid),
>> > - fsparam_u32("hidepid", Opt_hidepid),
>> > + fsparam_string("hidepid", Opt_hidepid),
>> > fsparam_string("subset", Opt_subset),
>> > {}
>> > };
>>
>> As I read fs_parser.c fs_param_is_u32 handles string inputs and turns them
>> into numbers, and it handles binary numbers. However fs_param_is_string
>> appears to only handle strings. It appears to have not capacity to turn
>> raw binary numbers into strings.
>
> I use result only with hidepid_u32_spec and nobody modifies param->string.
> I do not use internal functions here.
>
> I don’t follow how a raw number can get here ?
I may be wrong but last I looked you can input raw numbers using the new
mount api. I have most of the details paged out at the moment,
but I believe that is why when you set a parameter in the new mount api
it takes a type.
>> So I think we probably need to fix fs_param_is_string to raw binary
>> numbers before we can safely make this change to fs/proc/root.c
>>
>> David am I reading the fs_parser.c code correctly? If I am are you ok
>> with a change like the above?
Eric
On Thu, Apr 02, 2020 at 11:05:21AM -0500, Eric W. Biederman wrote:
> Alexey Gladkov <[email protected]> writes:
>
> > The hidepid parameter values are becoming more and more and it becomes
> > difficult to remember what each new magic number means.
>
> In principle I like this change. In practice I think you have just
> broken ABI compatiblity with the new mount ABI.
>
> In particular the following line seems broken.
>
> > diff --git a/fs/proc/root.c b/fs/proc/root.c
> > index dbcd96f07c7a..ba782d6e6197 100644
> > --- a/fs/proc/root.c
> > +++ b/fs/proc/root.c
> > @@ -45,7 +45,7 @@ enum proc_param {
> >
> > static const struct fs_parameter_spec proc_fs_parameters[] = {
> > fsparam_u32("gid", Opt_gid),
> > - fsparam_u32("hidepid", Opt_hidepid),
> > + fsparam_string("hidepid", Opt_hidepid),
> > fsparam_string("subset", Opt_subset),
> > {}
> > };
>
> As I read fs_parser.c fs_param_is_u32 handles string inputs and turns them
> into numbers, and it handles binary numbers.
Yes, you can use: fsconfig(fsfd, FSCONFIG_SET_BINARY, ...); but in this
case the type of parameter will be fs_value_is_blob [1]. This kind of
parameters is handled by fs_param_is_blob(). The fs_param_is_u32 can
handle only parametes with fs_value_is_string type [2].
Am I missing something?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/fsopen.c#n405
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/fs_parser.c#n215
> However fs_param_is_string
> appears to only handle strings. It appears to have not capacity to turn
> raw binary numbers into strings.
>
> So I think we probably need to fix fs_param_is_string to raw binary
> numbers before we can safely make this change to fs/proc/root.c
>
> David am I reading the fs_parser.c code correctly? If I am are you ok
> with a change like the above?
>
> Eric
>
--
Rgrds, legion