[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200618134825.487467-1-areber@redhat.com>
Date: Thu, 18 Jun 2020 15:48:22 +0200
From: Adrian Reber <areber@...hat.com>
To: Christian Brauner <christian.brauner@...ntu.com>,
Eric Biederman <ebiederm@...ssion.com>,
Pavel Emelyanov <ovzxemul@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
Andrei Vagin <avagin@...il.com>,
Nicolas Viennot <Nicolas.Viennot@...sigma.com>,
Michał Cłapiński
<mclapinski@...gle.com>, Kamil Yurtsever <kyurtsever@...gle.com>,
Dirk Petersen <dipeit@...il.com>,
Christine Flood <chf@...hat.com>,
Casey Schaufler <casey@...aufler-ca.com>
Cc: Mike Rapoport <rppt@...ux.ibm.com>,
Radostin Stoyanov <rstoyanov1@...il.com>,
Adrian Reber <areber@...hat.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Serge Hallyn <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>,
Sargun Dhillon <sargun@...gun.me>,
Arnd Bergmann <arnd@...db.de>,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, selinux@...r.kernel.org,
Eric Paris <eparis@...isplace.org>,
Jann Horn <jannh@...gle.com>, linux-fsdevel@...r.kernel.org
Subject: [PATCH v3 0/3] capabilities: Introduce CAP_CHECKPOINT_RESTORE
This is v3 of the 'Introduce CAP_CHECKPOINT_RESTORE' patchset. There
is only one change from v2:
* made if condition easier to read as requested by Cyrill
Besides that there were no further comments on the changes proposed in
this patchset.
There was the discussion from Andrei that PTRACE_O_SUSPEND_SECCOMP is
also needed for checkpointing. CRIU already has the possibility to
detect if a process is using seccomp and could so tell the user that
it cannot checkpoint a process if the process is using seccomp. As
seccomp has not come up in the requests from users to use CRIU as
non-root so far and as there was some push back from Christian to allow
PTRACE_O_SUSPEND_SECCOMP if CAP_CHECKPOINT_RESTORE is set I would like
to leave this open for the future.
Another discussion was around relaxing the existing map_files check from
capable() to ns_capable() or even completely removing it. Even if this
happens we still need CAP_CHECKPOINT_RESTORE and the removal or change
to ns_capable() is not blocked by this patchset.
Besides that there was nothing speaking against CAP_CHECKPOINT_RESTORE
during the v2 discussions.
Adrian Reber (2):
capabilities: Introduce CAP_CHECKPOINT_RESTORE
selftests: add clone3() CAP_CHECKPOINT_RESTORE test
Nicolas Viennot (1):
prctl: Allow ptrace capable processes to change exe_fd
fs/proc/base.c | 8 +-
include/linux/capability.h | 6 +
include/uapi/linux/capability.h | 9 +-
kernel/pid.c | 2 +-
kernel/pid_namespace.c | 2 +-
kernel/sys.c | 21 +-
security/selinux/include/classmap.h | 5 +-
tools/testing/selftests/clone3/Makefile | 4 +-
.../clone3/clone3_cap_checkpoint_restore.c | 203 ++++++++++++++++++
9 files changed, 245 insertions(+), 15 deletions(-)
create mode 100644 tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c
base-commit: 5fcb9628fd1227a5f11d87171cb1b8b5c414d9d9
--
2.26.2
Powered by blists - more mailing lists