From: Alexey Gladkov <gladkov.alexey@gmail.com> To: LKML <linux-kernel@vger.kernel.org>, Kernel Hardening <kernel-hardening@lists.openwall.com>, Linux API <linux-api@vger.kernel.org>, Linux FS Devel <linux-fsdevel@vger.kernel.org>, Linux Security Module <linux-security-module@vger.kernel.org> Cc: Akinobu Mita <akinobu.mita@gmail.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Alexey Dobriyan <adobriyan@gmail.com>, Alexey Gladkov <gladkov.alexey@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Andy Lutomirski <luto@kernel.org>, Daniel Micay <danielmicay@gmail.com>, Djalal Harouni <tixxdz@gmail.com>, "Dmitry V . Levin" <ldv@altlinux.org>, "Eric W . Biederman" <ebiederm@xmission.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@kernel.org>, "J . Bruce Fields" <bfields@fieldses.org>, Jeff Layton <jlayton@poochiereds.net>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Linus Torvalds <torvalds@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Solar Designer <solar@openwall.com> Subject: [PATCH v8 00/11] proc: modernize proc to support multiple private instances Date: Mon, 10 Feb 2020 16:05:08 +0100 [thread overview] Message-ID: <20200210150519.538333-1-gladkov.alexey@gmail.com> (raw) Greetings! Preface: -------- This is patchset v8 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 v5.4-rc7-49-g0e3f1ad80fc8 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=2 0 0 # mount -o hidepid=1 -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 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=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=pidfs' 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: ---------- # v8: * Started using RCU lock to clean dcache entries as Linus Torvalds suggested. # v7: * 'pidonly=1' renamed to 'subset=pidfs' as Alexey Dobriyan suggested. * HIDEPID_* moved to uapi/ as they are user interface to mount(). Suggested-by Alexey Dobriyan <adobriyan@gmail.com> # v6: * 'hidepid=' and 'gid=' mount options are moved from pid namespace to superblock. * 'newinstance' mount option removed as Eric W. Biederman suggested. 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 <luto@kernel.org> * Fixed order of commit, Suggested-by: Andy Lutomirski <luto@kernel.org> * 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 <luto@kernel.org> * 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 (11): proc: Rename struct proc_fs_info to proc_fs_opts proc: add proc_fs_info struct to store proc information proc: move /proc/{self|thread-self} dentries to proc_fs_info proc: move hide_pid, pid_gid from pid_namespace to proc_fs_info proc: add helpers to set and get proc hidepid and gid mount options proc: support mounting procfs instances inside same pid namespace proc: flush task dcache entries from all procfs instances 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=pidfs" options and new mount behavior proc: Move hidepid values to uapi as they are user interface to mount Documentation/filesystems/proc.txt | 53 +++++++++++ fs/locks.c | 6 +- fs/proc/base.c | 66 ++++++++++---- fs/proc/generic.c | 9 ++ fs/proc/inode.c | 21 +++-- fs/proc/internal.h | 30 ++++++ fs/proc/root.c | 141 +++++++++++++++++++++++------ fs/proc/self.c | 4 +- fs/proc/thread_self.c | 6 +- fs/proc_namespace.c | 14 +-- include/linux/pid_namespace.h | 14 +-- include/linux/proc_fs.h | 25 ++++- include/uapi/linux/proc_fs.h | 13 +++ 13 files changed, 324 insertions(+), 78 deletions(-) create mode 100644 include/uapi/linux/proc_fs.h -- 2.24.1
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Gladkov <gladkov.alexey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Kernel Hardening <kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linux FS Devel <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linux Security Module <linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Cc: Akinobu Mita <akinobu.mita-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Alexander Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>, Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Alexey Gladkov <gladkov.alexey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Daniel Micay <danielmicay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Djalal Harouni <tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, "Dmitry V . Levin" <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>, "Eric W . Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>, Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>, Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "J . Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>, Jeff Layton <jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>, Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Solar Designer <solar-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> Subject: [PATCH v8 00/11] proc: modernize proc to support multiple private instances Date: Mon, 10 Feb 2020 16:05:08 +0100 [thread overview] Message-ID: <20200210150519.538333-1-gladkov.alexey@gmail.com> (raw) Greetings! Preface: -------- This is patchset v8 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 v5.4-rc7-49-g0e3f1ad80fc8 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=2 0 0 # mount -o hidepid=1 -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 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=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=pidfs' 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: ---------- # v8: * Started using RCU lock to clean dcache entries as Linus Torvalds suggested. # v7: * 'pidonly=1' renamed to 'subset=pidfs' as Alexey Dobriyan suggested. * HIDEPID_* moved to uapi/ as they are user interface to mount(). Suggested-by Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> # v6: * 'hidepid=' and 'gid=' mount options are moved from pid namespace to superblock. * 'newinstance' mount option removed as Eric W. Biederman suggested. 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 <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> * Fixed order of commit, Suggested-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> * 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 <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> * 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 (11): proc: Rename struct proc_fs_info to proc_fs_opts proc: add proc_fs_info struct to store proc information proc: move /proc/{self|thread-self} dentries to proc_fs_info proc: move hide_pid, pid_gid from pid_namespace to proc_fs_info proc: add helpers to set and get proc hidepid and gid mount options proc: support mounting procfs instances inside same pid namespace proc: flush task dcache entries from all procfs instances 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=pidfs" options and new mount behavior proc: Move hidepid values to uapi as they are user interface to mount Documentation/filesystems/proc.txt | 53 +++++++++++ fs/locks.c | 6 +- fs/proc/base.c | 66 ++++++++++---- fs/proc/generic.c | 9 ++ fs/proc/inode.c | 21 +++-- fs/proc/internal.h | 30 ++++++ fs/proc/root.c | 141 +++++++++++++++++++++++------ fs/proc/self.c | 4 +- fs/proc/thread_self.c | 6 +- fs/proc_namespace.c | 14 +-- include/linux/pid_namespace.h | 14 +-- include/linux/proc_fs.h | 25 ++++- include/uapi/linux/proc_fs.h | 13 +++ 13 files changed, 324 insertions(+), 78 deletions(-) create mode 100644 include/uapi/linux/proc_fs.h -- 2.24.1
next reply other threads:[~2020-02-10 15:06 UTC|newest] Thread overview: 176+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-10 15:05 Alexey Gladkov [this message] 2020-02-10 15:05 ` [PATCH v8 00/11] proc: modernize proc to support multiple private instances Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 01/11] proc: Rename struct proc_fs_info to proc_fs_opts Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 02/11] proc: add proc_fs_info struct to store proc information Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 03/11] proc: move /proc/{self|thread-self} dentries to proc_fs_info Alexey Gladkov 2020-02-10 15:05 ` Alexey Gladkov 2020-02-10 18:23 ` Andy Lutomirski 2020-02-10 18:23 ` Andy Lutomirski 2020-02-10 18:23 ` Andy Lutomirski 2020-02-12 15:00 ` Alexey Gladkov 2020-02-12 15:00 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 04/11] proc: move hide_pid, pid_gid from pid_namespace " Alexey Gladkov 2020-02-10 15:05 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 05/11] proc: add helpers to set and get proc hidepid and gid mount options Alexey Gladkov 2020-02-10 18:30 ` Andy Lutomirski 2020-02-10 18:30 ` Andy Lutomirski 2020-02-10 18:30 ` Andy Lutomirski 2020-02-12 14:57 ` Alexey Gladkov 2020-02-12 14:57 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 06/11] proc: support mounting procfs instances inside same pid namespace Alexey Gladkov 2020-02-10 15:05 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances Alexey Gladkov 2020-02-10 17:46 ` Linus Torvalds 2020-02-10 17:46 ` Linus Torvalds 2020-02-10 17:46 ` Linus Torvalds 2020-02-10 19:23 ` Al Viro 2020-02-10 19:23 ` Al Viro 2020-02-11 1:36 ` Eric W. Biederman 2020-02-11 1:36 ` Eric W. Biederman 2020-02-11 1:36 ` Eric W. Biederman 2020-02-11 4:01 ` Eric W. Biederman 2020-02-11 4:01 ` Eric W. Biederman 2020-02-11 4:01 ` Eric W. Biederman 2020-02-12 14:49 ` Alexey Gladkov 2020-02-12 14:49 ` Alexey Gladkov 2020-02-12 14:59 ` Eric W. Biederman 2020-02-12 14:59 ` Eric W. Biederman 2020-02-12 14:59 ` Eric W. Biederman 2020-02-12 17:08 ` Alexey Gladkov 2020-02-12 17:08 ` Alexey Gladkov 2020-02-12 18:45 ` Linus Torvalds 2020-02-12 18:45 ` Linus Torvalds 2020-02-12 18:45 ` Linus Torvalds 2020-02-12 19:16 ` Eric W. Biederman 2020-02-12 19:16 ` Eric W. Biederman 2020-02-12 19:16 ` Eric W. Biederman 2020-02-12 19:49 ` Linus Torvalds 2020-02-12 19:49 ` Linus Torvalds 2020-02-12 19:49 ` Linus Torvalds 2020-02-12 20:03 ` Al Viro 2020-02-12 20:03 ` Al Viro 2020-02-12 20:35 ` Linus Torvalds 2020-02-12 20:35 ` Linus Torvalds 2020-02-12 20:35 ` Linus Torvalds 2020-02-12 20:38 ` Al Viro 2020-02-12 20:38 ` Al Viro 2020-02-12 20:41 ` Al Viro 2020-02-12 20:41 ` Al Viro 2020-02-12 21:02 ` Linus Torvalds 2020-02-12 21:02 ` Linus Torvalds 2020-02-12 21:02 ` Linus Torvalds 2020-02-12 21:46 ` Eric W. Biederman 2020-02-12 21:46 ` Eric W. Biederman 2020-02-12 21:46 ` Eric W. Biederman 2020-02-13 0:48 ` Linus Torvalds 2020-02-13 0:48 ` Linus Torvalds 2020-02-13 0:48 ` Linus Torvalds 2020-02-13 4:37 ` Eric W. Biederman 2020-02-13 4:37 ` Eric W. Biederman 2020-02-13 5:55 ` Al Viro 2020-02-13 21:30 ` Linus Torvalds 2020-02-13 21:30 ` Linus Torvalds 2020-02-13 22:23 ` Al Viro 2020-02-13 22:47 ` Linus Torvalds 2020-02-13 22:47 ` Linus Torvalds 2020-02-14 14:15 ` Eric W. Biederman 2020-02-14 14:15 ` Eric W. Biederman 2020-02-14 3:48 ` Eric W. Biederman 2020-02-14 3:48 ` Eric W. Biederman 2020-02-20 20:46 ` [PATCH 0/7] proc: Dentry flushing without proc_mnt Eric W. Biederman 2020-02-20 20:46 ` Eric W. Biederman 2020-02-20 20:47 ` [PATCH 1/7] proc: Rename in proc_inode rename sysctl_inodes sibling_inodes Eric W. Biederman 2020-02-20 20:47 ` Eric W. Biederman 2020-02-20 20:48 ` [PATCH 2/7] proc: Generalize proc_sys_prune_dcache into proc_prune_siblings_dcache Eric W. Biederman 2020-02-20 20:48 ` Eric W. Biederman 2020-02-20 20:49 ` [PATCH 3/7] proc: Mov rcu_read_(lock|unlock) in proc_prune_siblings_dcache Eric W. Biederman 2020-02-20 20:49 ` Eric W. Biederman 2020-02-20 22:33 ` Linus Torvalds 2020-02-20 22:33 ` Linus Torvalds 2020-02-20 20:49 ` [PATCH 4/7] proc: Use d_invalidate " Eric W. Biederman 2020-02-20 20:49 ` Eric W. Biederman 2020-02-20 22:43 ` Linus Torvalds 2020-02-20 22:43 ` Linus Torvalds 2020-02-20 22:54 ` Al Viro 2020-02-20 23:00 ` Linus Torvalds 2020-02-20 23:00 ` Linus Torvalds 2020-02-20 23:03 ` Al Viro 2020-02-20 23:39 ` Eric W. Biederman 2020-02-20 23:39 ` Eric W. Biederman 2020-02-20 20:51 ` [PATCH 5/7] proc: Clear the pieces of proc_inode that proc_evict_inode cares about Eric W. Biederman 2020-02-20 20:51 ` Eric W. Biederman 2020-02-20 20:52 ` [PATCH 6/7] proc: Use a list of inodes to flush from proc Eric W. Biederman 2020-02-20 20:52 ` Eric W. Biederman 2020-02-20 20:52 ` [PATCH 7/7] proc: Ensure we see the exit of each process tid exactly once Eric W. Biederman 2020-02-20 20:52 ` Eric W. Biederman 2020-02-21 16:50 ` Oleg Nesterov 2020-02-22 15:46 ` Eric W. Biederman 2020-02-22 15:46 ` Eric W. Biederman 2020-02-20 23:02 ` [PATCH 0/7] proc: Dentry flushing without proc_mnt Linus Torvalds 2020-02-20 23:02 ` Linus Torvalds 2020-02-20 23:07 ` Al Viro 2020-02-20 23:37 ` Eric W. Biederman 2020-02-20 23:37 ` Eric W. Biederman 2020-02-24 16:25 ` [PATCH v2 0/6] " Eric W. Biederman 2020-02-24 16:25 ` Eric W. Biederman 2020-02-24 16:26 ` [PATCH v2 1/6] proc: Rename in proc_inode rename sysctl_inodes sibling_inodes Eric W. Biederman 2020-02-24 16:26 ` Eric W. Biederman 2020-02-24 16:27 ` [PATCH v2 2/6] proc: Generalize proc_sys_prune_dcache into proc_prune_siblings_dcache Eric W. Biederman 2020-02-24 16:27 ` Eric W. Biederman 2020-02-24 16:27 ` [PATCH v2 3/6] proc: In proc_prune_siblings_dcache cache an aquired super block Eric W. Biederman 2020-02-24 16:27 ` Eric W. Biederman 2020-02-24 16:28 ` [PATCH v2 4/6] proc: Use d_invalidate in proc_prune_siblings_dcache Eric W. Biederman 2020-02-24 16:28 ` Eric W. Biederman 2020-02-24 16:28 ` [PATCH v2 5/6] proc: Clear the pieces of proc_inode that proc_evict_inode cares about Eric W. Biederman 2020-02-24 16:28 ` Eric W. Biederman 2020-02-24 16:29 ` [PATCH v2 6/6] proc: Use a list of inodes to flush from proc Eric W. Biederman 2020-02-24 16:29 ` Eric W. Biederman 2020-02-28 20:17 ` [PATCH 0/3] proc: Actually honor the mount options Eric W. Biederman 2020-02-28 20:17 ` Eric W. Biederman 2020-02-28 20:18 ` [PATCH 1/3] uml: Don't consult current to find the proc_mnt in mconsole_proc Eric W. Biederman 2020-02-28 20:18 ` Eric W. Biederman 2020-02-28 20:18 ` [PATCH 2/3] uml: Create a private mount of proc for mconsole Eric W. Biederman 2020-02-28 20:18 ` Eric W. Biederman 2020-02-28 20:30 ` Christian Brauner 2020-02-28 21:28 ` Eric W. Biederman 2020-02-28 21:28 ` Eric W. Biederman 2020-02-28 21:59 ` Christian Brauner 2020-02-28 20:19 ` [PATCH 3/3] proc: Remove the now unnecessary internal mount of proc Eric W. Biederman 2020-02-28 20:19 ` Eric W. Biederman 2020-02-28 20:39 ` Christian Brauner 2020-02-28 21:40 ` Eric W. Biederman 2020-02-28 21:40 ` Eric W. Biederman 2020-02-29 3:25 ` kbuild test robot 2020-02-29 3:25 ` kbuild test robot 2020-02-29 4:49 ` Eric W. Biederman 2020-02-29 4:49 ` Eric W. Biederman 2020-03-02 23:01 ` [kbuild-all] " Philip Li 2020-03-02 23:01 ` Philip Li 2020-03-12 2:03 ` [kbuild-all] " Li Zhijian 2020-03-12 2:03 ` Li Zhijian 2020-02-29 4:23 ` kbuild test robot 2020-02-29 4:23 ` kbuild test robot 2020-02-28 22:34 ` [PATCH 4/3] pid: Improve the comment about waiting in zap_pid_ns_processes Eric W. Biederman 2020-02-28 22:34 ` Eric W. Biederman 2020-02-29 2:59 ` Christian Brauner 2020-02-14 3:49 ` [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances Eric W. Biederman 2020-02-14 3:49 ` Eric W. Biederman 2020-02-12 19:47 ` Al Viro 2020-02-12 19:47 ` Al Viro 2020-02-11 22:45 ` Al Viro 2020-02-11 22:45 ` Al Viro 2020-02-12 14:26 ` Alexey Gladkov 2020-02-12 14:26 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 08/11] proc: instantiate only pids that we can ptrace on 'hidepid=4' mount option Alexey Gladkov 2020-02-10 16:29 ` Jordan Glover 2020-02-10 16:29 ` Jordan Glover 2020-02-12 14:34 ` Alexey Gladkov 2020-02-12 14:34 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 09/11] proc: add option to mount only a pids subset Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 10/11] docs: proc: add documentation for "hidepid=4" and "subset=pidfs" options and new mount behavior Alexey Gladkov 2020-02-10 18:29 ` Andy Lutomirski 2020-02-10 18:29 ` Andy Lutomirski 2020-02-10 18:29 ` Andy Lutomirski 2020-02-12 16:03 ` Alexey Gladkov 2020-02-12 16:03 ` Alexey Gladkov 2020-02-10 15:05 ` [PATCH v8 11/11] proc: Move hidepid values to uapi as they are user interface to mount Alexey Gladkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200210150519.538333-1-gladkov.alexey@gmail.com \ --to=gladkov.alexey@gmail.com \ --cc=adobriyan@gmail.com \ --cc=akinobu.mita@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=bfields@fieldses.org \ --cc=corbet@lwn.net \ --cc=danielmicay@gmail.com \ --cc=ebiederm@xmission.com \ --cc=gregkh@linuxfoundation.org \ --cc=jlayton@poochiereds.net \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=ldv@altlinux.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mingo@kernel.org \ --cc=oleg@redhat.com \ --cc=solar@openwall.com \ --cc=tixxdz@gmail.com \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.