* [PATCH] netlabel_domainhash.c: Use built-in RCU list checking
From: madhuparnabhowmik10 @ 2020-02-18 18:41 UTC (permalink / raw)
To: paul, davem
Cc: netdev, linux-security-module, linux-kernel, joel, frextrite,
linux-kernel-mentees, paulmck, Madhuparna Bhowmik
From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
list_for_each_entry_rcu() has built-in RCU and lock checking.
Pass cond argument to list_for_each_entry_rcu() to silence
false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
by default.
Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
---
net/netlabel/netlabel_domainhash.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netlabel/netlabel_domainhash.c b/net/netlabel/netlabel_domainhash.c
index f5d34da0646e..a1f2320ecc16 100644
--- a/net/netlabel/netlabel_domainhash.c
+++ b/net/netlabel/netlabel_domainhash.c
@@ -143,7 +143,8 @@ static struct netlbl_dom_map *netlbl_domhsh_search(const char *domain,
if (domain != NULL) {
bkt = netlbl_domhsh_hash(domain);
bkt_list = &netlbl_domhsh_rcu_deref(netlbl_domhsh)->tbl[bkt];
- list_for_each_entry_rcu(iter, bkt_list, list)
+ list_for_each_entry_rcu(iter, bkt_list, list,
+ lockdep_is_held(&netlbl_domhsh_lock))
if (iter->valid &&
netlbl_family_match(iter->family, family) &&
strcmp(iter->domain, domain) == 0)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v7 01/12] capabilities: introduce CAP_PERFMON to kernel and user space
From: James Morris @ 2020-02-18 19:21 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <f56fbb5c-1477-44d5-7346-85a1ca0869dc@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Introduce CAP_PERFMON capability designed to secure system performance
> monitoring and observability operations so that CAP_PERFMON would assist
> CAP_SYS_ADMIN capability in its governing role for performance
> monitoring and observability subsystems.
Acked-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 02/12] perf/core: open access to the core for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:22 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <e68be109-7174-2c9e-11a9-9770a6316834@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to monitoring of kernel code, cpus, tracepoints and
> namespaces data for a CAP_PERFMON privileged process. Providing the
> access under CAP_PERFMON capability singly, without the rest of
> CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials
> and makes operation more secure.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39
> principle of least privilege: A security design principle that states
> that a process or program be granted only those privileges (e.g.,
> capabilities) necessary to accomplish its legitimate function, and only
> for the time that such privileges are actually required)
>
> For backward compatibility reasons access to perf_events subsystem
> remains open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN
> usage for secure perf_events monitoring is discouraged with respect to
> CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 03/12] perf/core: open access to probes for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:22 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <3364fa26-b5d1-1808-aaee-c057f26e0eb4@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to monitoring via kprobes and uprobes and eBPF tracing for
> CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials,
> excludes chances to misuse the credentials and makes operation more
> secure.
>
> perf kprobes and uprobes are used by ftrace and eBPF. perf probe uses
> ftrace to define new kprobe events, and those events are treated as
> tracepoint events. eBPF defines new probes via perf_event_open interface
> and then the probes are used in eBPF tracing.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39
> principle of least privilege: A security design principle that states
> that a process or program be granted only those privileges (e.g.,
> capabilities) necessary to accomplish its legitimate function, and only
> for the time that such privileges are actually required)
>
> For backward compatibility reasons access to perf_events subsystem
> remains open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN
> usage for secure perf_events monitoring is discouraged with respect to
> CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 04/12] perf tool: extend Perf tool with CAP_PERFMON capability support
From: James Morris @ 2020-02-18 19:24 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <5f961a07-36d0-d8f4-1895-6cfc38bcb81e@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Extend error messages to mention CAP_PERFMON capability as an option
> to substitute CAP_SYS_ADMIN capability for secure system performance
> monitoring and observability. Make perf_event_paranoid_check() and
> __cmd_ftrace() to be aware of CAP_PERFMON capability.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39
> principle of least privilege: A security design principle that states
> that a process or program be granted only those privileges (e.g.,
> capabilities) necessary to accomplish its legitimate function, and only
> for the time that such privileges are actually required)
>
> For backward compatibility reasons access to perf_events subsystem
> remains open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN
> usage for secure perf_events monitoring is discouraged with respect to
> CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 05/12] drm/i915/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:25 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <8b408c10-9bb0-4b08-8681-93c0f4a1132e@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to i915_perf monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation more secure.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39
> principle of least privilege: A security design principle that states
> that a process or program be granted only those privileges (e.g.,
> capabilities) necessary to accomplish its legitimate function, and only
> for the time that such privileges are actually required)
>
> For backward compatibility reasons access to i915_events subsystem
> remains open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN
> usage for secure i915_events monitoring is discouraged with respect to
> CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 06/12] trace/bpf_trace: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:25 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <fc689865-f8ff-1e85-ac0c-b2f1c28b7eb6@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to bpf_trace monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation more secure.
>
> CAP_PERFMON implements the principal of least privilege for performance
> monitoring and observability operations (POSIX IEEE 1003.1e 2.2.2.39
> principle of least privilege: A security design principle that states
> that a process or program be granted only those privileges (e.g.,
> capabilities) necessary to accomplish its legitimate function, and only
> for the time that such privileges are actually required)
>
> For backward compatibility reasons access to bpf_trace monitoring
> remains open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN
> usage for secure bpf_trace monitoring is discouraged with respect to
> CAP_PERFMON capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 07/12] powerpc/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:28 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <b144d52b-6040-4660-46d1-2c8c58e98e7e@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 08/12] parisc/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:29 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <29e45605-7a3c-944b-7bea-5959f8ff0793@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC PATCH] security: <linux/lsm_hooks.h>: fix all kernel-doc warnings
From: Randy Dunlap @ 2020-02-18 19:30 UTC (permalink / raw)
To: Stephen Smalley, LKML, linux-security-module
Cc: John Johansen, Kees Cook, Micah Morton, James Morris,
Serge E. Hallyn, Paul Moore, Eric Paris, Casey Schaufler,
Kentaro Takeda, Tetsuo Handa
In-Reply-To: <ec4e5117-08b6-d4df-fb08-deb553ebdc73@tycho.nsa.gov>
On 2/18/20 6:03 AM, Stephen Smalley wrote:
> On 2/16/20 2:08 AM, Randy Dunlap wrote:
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Fix all kernel-doc warnings in <linux/lsm_hooks.h>.
>> Fixes the following warnings:
>>
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'quotactl' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'quota_on' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'sb_free_mnt_opts' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'sb_eat_lsm_opts' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'sb_kern_mount' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'sb_show_options' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'sb_add_mnt_opt' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'd_instantiate' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'getprocattr' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'setprocattr' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'locked_down' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'perf_event_open' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'perf_event_alloc' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'perf_event_free' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'perf_event_read' not described in 'security_list_options'
>> ../include/linux/lsm_hooks.h:1830: warning: Function parameter or member 'perf_event_write' not described in 'security_list_options'
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: John Johansen <john.johansen@canonical.com>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Micah Morton <mortonm@chromium.org>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: "Serge E. Hallyn" <serge@hallyn.com>
>> Cc: linux-security-module@vger.kernel.org
>> Cc: Paul Moore <paul@paul-moore.com>
>> Cc: Stephen Smalley <sds@tycho.nsa.gov>
>> Cc: Eric Paris <eparis@parisplace.org>
>> Cc: Casey Schaufler <casey@schaufler-ca.com>
>> Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
>> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> ---
>> Notes:
>> a. The location for some of these might need to be modified.
>> b. 'locked_down' was just missing a final ':'.
>> c. Added a new section: Security hooks for perf events.
>>
>> include/linux/lsm_hooks.h | 36 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 35 insertions(+), 1 deletion(-)
>>
>> --- lnx-56-rc1.orig/include/linux/lsm_hooks.h
>> +++ lnx-56-rc1/include/linux/lsm_hooks.h
>> @@ -136,6 +140,10 @@
>> * @sb superblock being remounted
>> * @data contains the filesystem-specific data.
>> * Return 0 if permission is granted.
>> + * @sb_kern_mount:
>> + * Mount this @sb if allowed by permissions.
>> + * @sb_show_options:
>> + * Show (print on @m) mount options for this @sb.
>> * @sb_umount:
>> * Check permission before the @mnt file system is unmounted.
>> * @mnt contains the mounted file system.
>
> Thanks for doing this. Note that some of the existing kernel-doc comments for these hooks include a separate line describing each parameter (not just embedded in the function description) and a line describing the return value. Is that optional for kernel-doc? Obviously what you have added here is an improvement, just wondering whether it suffices or needs further augmentation.
Hi Stephen,
The additional kernel-doc comments that you refer to are obviously Good to Have,
but they are not required. I didn't feel comfortable or qualified to add
all of that info, but if anyone wants to help/contribute, please do so.
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v7 09/12] drivers/perf: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:43 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <48baecd5-a015-3dbf-f774-9f2caee13893@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v7 10/12] drivers/oprofile: open access for CAP_PERFMON privileged process
From: James Morris @ 2020-02-18 19:44 UTC (permalink / raw)
To: Alexey Budankov
Cc: Serge Hallyn, Stephen Smalley, Peter Zijlstra,
Arnaldo Carvalho de Melo, Ingo Molnar,
joonas.lahtinen@linux.intel.com, Alexei Starovoitov, Will Deacon,
Paul Mackerras, Helge Deller, Thomas Gleixner, Andi Kleen,
Stephane Eranian, Igor Lubashev, Jiri Olsa, linux-kernel,
intel-gfx@lists.freedesktop.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-arm-kernel, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, oprofile-list,
linux-doc@vger.kernel.org, linux-man
In-Reply-To: <046beedf-e074-58e2-579d-df535799169c@linux.intel.com>
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budankov <alexey.budankov@linux.intel.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH] net: netlabel: Use built-in RCU list checking
From: David Miller @ 2020-02-18 20:43 UTC (permalink / raw)
To: madhuparnabhowmik10
Cc: paul, netdev, linux-security-module, linux-kernel, joel,
frextrite, linux-kernel-mentees, paulmck
In-Reply-To: <20200218181718.7258-1-madhuparnabhowmik10@gmail.com>
From: madhuparnabhowmik10@gmail.com
Date: Tue, 18 Feb 2020 23:47:18 +0530
> From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
>
> list_for_each_entry_rcu() has built-in RCU and lock checking.
>
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
>
> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netlabel_domainhash.c: Use built-in RCU list checking
From: David Miller @ 2020-02-18 20:44 UTC (permalink / raw)
To: madhuparnabhowmik10
Cc: paul, netdev, linux-security-module, linux-kernel, joel,
frextrite, linux-kernel-mentees, paulmck
In-Reply-To: <20200218184132.20363-1-madhuparnabhowmik10@gmail.com>
From: madhuparnabhowmik10@gmail.com
Date: Wed, 19 Feb 2020 00:11:32 +0530
> From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
>
> list_for_each_entry_rcu() has built-in RCU and lock checking.
>
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
>
> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Applied.
^ permalink raw reply
* Re: kernel BUG at lib/assoc_array.c:LINE!
From: Jarkko Sakkinen @ 2020-02-18 21:12 UTC (permalink / raw)
To: dhowells; +Cc: jmorris, keyrings, linux-security-module, serge
In-Reply-To: <000000000000f4bf93059db8b081@google.com>
On Mon, Feb 03, 2020 at 08:44:11PM -0800, syzbot wrote:
> Hello, >
> syzbot found the following crash on:
>
> HEAD commit: 46d6b7be Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11383a79e00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6dda7ccc1e75a63f
> dashboard link: https://syzkaller.appspot.com/bug?extid=23e14950fa7550d86091
> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+23e14950fa7550d86091@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> kernel BUG at lib/assoc_array.c:652!
> invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 2778 Comm: kworker/0:37 Not tainted 5.5.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: afs afs_manage_cell
> RIP: 0010:assoc_array_insert_into_terminal_node lib/assoc_array.c:652 [inline]
> RIP: 0010:assoc_array_insert+0x2baa/0x2bd0 lib/assoc_array.c:1001
> Code: 0f 0b e8 a9 64 d4 fd 0f 0b e8 a2 64 d4 fd 0f 0b e8 9b 64 d4 fd 0f 0b e8 94 64 d4 fd 0f 0b e8 8d 64 d4 fd 0f 0b e8 86 64 d4 fd <0f> 0b e8 7f 64 d4 fd 0f 0b e8 78 64 d4 fd 0f 0b e8 71 64 d4 fd 0f
> RSP: 0018:ffffc900087ff810 EFLAGS: 00010293
> RAX: ffffffff83a25a7a RBX: 1ffff11012d568af RCX: ffff88809f34a580
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffffc900087ff920 R08: ffffffff83a249fd R09: ffffffff83538f4f
> R10: ffff88809f34a580 R11: 0000000000000004 R12: ffff888096ab4588
> R13: ffff888096ab4500 R14: ffff888096ab4578 R15: dffffc0000000000
> FS: 0000000000000000(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000738000 CR3: 0000000054a3b000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> __key_link_begin+0xfe/0x230 security/keys/keyring.c:1316
> construct_alloc_key security/keys/request_key.c:404 [inline]
> construct_key_and_link security/keys/request_key.c:499 [inline]
> request_key_and_link+0x9b6/0x1680 security/keys/request_key.c:637
> request_key_tag+0x53/0x190 security/keys/request_key.c:701
> dns_query+0x266/0x6c0 net/dns_resolver/dns_query.c:128
> afs_dns_query+0xdd/0x320 fs/afs/addr_list.c:249
> afs_update_cell fs/afs/cell.c:391 [inline]
> afs_manage_cell+0xda2/0x1500 fs/afs/cell.c:693
> process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
> worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
> kthread+0x332/0x350 kernel/kthread.c:255
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> Modules linked in:
> ---[ end trace 9dabb2deade74362 ]---
> RIP: 0010:assoc_array_insert_into_terminal_node lib/assoc_array.c:652 [inline]
> RIP: 0010:assoc_array_insert+0x2baa/0x2bd0 lib/assoc_array.c:1001
> Code: 0f 0b e8 a9 64 d4 fd 0f 0b e8 a2 64 d4 fd 0f 0b e8 9b 64 d4 fd 0f 0b e8 94 64 d4 fd 0f 0b e8 8d 64 d4 fd 0f 0b e8 86 64 d4 fd <0f> 0b e8 7f 64 d4 fd 0f 0b e8 78 64 d4 fd 0f 0b e8 71 64 d4 fd 0f
> RSP: 0018:ffffc900087ff810 EFLAGS: 00010293
> RAX: ffffffff83a25a7a RBX: 1ffff11012d568af RCX: ffff88809f34a580
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffffc900087ff920 R08: ffffffff83a249fd R09: ffffffff83538f4f
> R10: ffff88809f34a580 R11: 0000000000000004 R12: ffff888096ab4588
> R13: ffff888096ab4500 R14: ffff888096ab4578 R15: dffffc0000000000
> FS: 0000000000000000(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000013e4978 CR3: 000000008adb2000 CR4: 00000000001406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
The arguments for request_key_and_link() are fairly constrained:
type == &key_type_dns_resolver
description == "afsdb:<cell name>"
domain_tag == net->key_domain
callout_info == "srv=1"
callout_len == 5
aux == NULL
dest_keyring == NULL
flags == KEY_ALLOC_IN_QUOTA
(manually resolved)
The only obvious moving part I see is the key type implementatio i.e.
net/dns_resolver/dns_key.c.
/Jarkko
^ permalink raw reply
* Re: [PATCH v26 10/22] x86/sgx: Linux Enclave Driver
From: Sean Christopherson @ 2020-02-18 22:12 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jethro Beekman, Jarkko Sakkinen, linux-kernel, x86, linux-sgx,
akpm, dave.hansen, nhorman, npmccallum, haitao.huang,
andriy.shevchenko, tglx, kai.svahn, bp, josh, luto, kai.huang,
rientjes, cedric.xing, puiterwijk, linux-security-module,
Haitao Huang
In-Reply-To: <033BCE0D-FA8C-40FB-849A-E401A5C6F6A3@amacapital.net>
On Sat, Feb 15, 2020 at 08:56:54AM -0800, Andy Lutomirski wrote:
>
> > On Feb 14, 2020, at 9:52 AM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> >
> > On Fri, Feb 14, 2020 at 09:40:00AM -0800, Andy Lutomirski wrote:
> >>
> >>
> >>>> On Feb 14, 2020, at 9:11 AM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> >>>
> >>> On Fri, Feb 14, 2020 at 10:24:10AM +0100, Jethro Beekman wrote:
> >>>>> On 2020-02-13 19:07, Sean Christopherson wrote:
> >>>>> On Thu, Feb 13, 2020 at 02:59:52PM +0100, Jethro Beekman wrote:
> >>>>>> On 2020-02-09 22:25, Jarkko Sakkinen wrote:
> >>>>>>> +/**
> >>>>>>> + * struct sgx_enclave_add_pages - parameter structure for the
> >>>>>>> + * %SGX_IOC_ENCLAVE_ADD_PAGE ioctl
> >>>>>>> + * @src: start address for the page data
> >>>>>>> + * @offset: starting page offset
> >>>>>>> + * @length: length of the data (multiple of the page size)
> >>>>>>> + * @secinfo: address for the SECINFO data
> >>>>>>> + * @flags: page control flags
> >>>>>>> + * @count: number of bytes added (multiple of the page size)
> >>>>>>> + */
> >>>>>>> +struct sgx_enclave_add_pages {
> >>>>>>> + __u64 src;
> >>>>>>> + __u64 offset;
> >>>>>>> + __u64 length;
> >>>>>>> + __u64 secinfo;
> >>>>>>> + __u64 flags;
> >>>>>>> + __u64 count;
> >>>>>>> +};
> >>>>>>
> >>>>>> Compared to the last time I looked at the patch set, this API removes the
> >>>>>> ability to measure individual pages chunks. That is not acceptable.
> >>>>>
> >>>>> Why is it not acceptable? E.g. what specific use case do you have that
> >>>>> _requires_ on measuring partial 4k pages of an enclave?
> >>>>
> >>>> The use case is someone gives me an enclave and I want to load it. If I don't
> >>>> load it exactly as the enclave author specified, the enclave hash will be
> >>>> different, and it won't work.
> >>>
> >>> And if our ABI says "thou shall measure in 4k chunks", then it's an invalid
> >>> enclave if its author generated MRENCLAVE using a different granularity.
> >>
> >> ISTM, unless there’s a particularly compelling reason, if an enclave is
> >> valid, we should be able to load it.
> >
> > That means we have to have a separate ioctl() for EEXTEND, otherwise we
> > can't handle EADD[0]->EADD[1]->EADD[2]->EEXTEND[0]->EEXTEND[1]->EEXTEND[2].
> >
> > I think we'd still want to keep the MEASURE flag for SGX_IOC_ENCLAVE_ADD_PAGE
> > so that we can optimize EADD[0]->EEXTEND[0]->EADD[1]->EEXTEND[1].
>
> Seems reasonable to me. I suppose such as ioctl could also be added later if
> there’s a need.
Assuming you're referring to the separate EEXTEND ioctl()...
Everyone:
Is a dedicated EEXTEND ioctl() needed now, i.e. is there an existing or
in-flight use case that would break by having only the MEASURE flag in
ADD_PAGE?
If the answer is 'no' from all parties, my preference would be to hold off
on adding it until there is an actual end user. To be clear, I'm not
against adding such an ioctl(), I just don't want to add code where the
only user is a kernel selftest.
^ permalink raw reply
* Re: [PATCH v3 11/25] inode: inode_owner_or_capable(): handle fsid mappings
From: Christoph Hellwig @ 2020-02-18 22:25 UTC (permalink / raw)
To: Christian Brauner
Cc: Stéphane Graber, Eric W. Biederman, Aleksa Sarai, Jann Horn,
smbarber, Seth Forshee, Alexander Viro, Alexey Dobriyan,
Serge Hallyn, James Morris, Kees Cook, Jonathan Corbet,
Phil Estes, linux-kernel, linux-fsdevel, containers,
linux-security-module, linux-api
In-Reply-To: <20200218143411.2389182-12-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 03:33:57PM +0100, Christian Brauner wrote:
> + if (is_userns_visible(inode->i_sb->s_iflags)) {
> + if (kuid_has_mapping(ns, inode->i_uid) && ns_capable(ns, CAP_FOWNER))
> + return true;
> + } else if (kfsuid_has_mapping(ns, inode->i_uid) && ns_capable(ns, CAP_FOWNER)) {
This adds some crazy long unreadable lines..
^ permalink raw reply
* Re: [PATCH v3 15/25] posix_acl: handle fsid mappings
From: Christoph Hellwig @ 2020-02-18 22:26 UTC (permalink / raw)
To: Christian Brauner
Cc: Stéphane Graber, Eric W. Biederman, Aleksa Sarai, Jann Horn,
smbarber, Seth Forshee, Alexander Viro, Alexey Dobriyan,
Serge Hallyn, James Morris, Kees Cook, Jonathan Corbet,
Phil Estes, linux-kernel, linux-fsdevel, containers,
linux-security-module, linux-api
In-Reply-To: <20200218143411.2389182-16-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 03:34:01PM +0100, Christian Brauner wrote:
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index 249672bf54fe..ed6112c9b804 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -22,6 +22,7 @@
> #include <linux/xattr.h>
> #include <linux/export.h>
> #include <linux/user_namespace.h>
> +#include <linux/fsuidgid.h>
>
> static struct posix_acl **acl_by_type(struct inode *inode, int type)
> {
> @@ -692,12 +693,12 @@ static void posix_acl_fix_xattr_userns(
> for (end = entry + count; entry != end; entry++) {
> switch(le16_to_cpu(entry->e_tag)) {
> case ACL_USER:
> - uid = make_kuid(from, le32_to_cpu(entry->e_id));
> - entry->e_id = cpu_to_le32(from_kuid(to, uid));
> + uid = make_kfsuid(from, le32_to_cpu(entry->e_id));
> + entry->e_id = cpu_to_le32(from_kfsuid(to, uid));
> break;
> case ACL_GROUP:
> - gid = make_kgid(from, le32_to_cpu(entry->e_id));
> - entry->e_id = cpu_to_le32(from_kgid(to, gid));
> + gid = make_kfsgid(from, le32_to_cpu(entry->e_id));
> + entry->e_id = cpu_to_le32(from_kfsgid(to, gid));
> break;
Before we touch this code any more it needs to move to the right place.
Poking into ACLs from generic xattr code is a complete layering
violation, and all this needs to be moved so that it is called by
the actual handlers called from the file systems.
^ permalink raw reply
* Re: [PATCH] net: netlabel: Use built-in RCU list checking
From: Paul Moore @ 2020-02-18 22:48 UTC (permalink / raw)
To: madhuparnabhowmik10
Cc: davem, netdev, linux-security-module, linux-kernel, joel,
frextrite, linux-kernel-mentees, paulmck
In-Reply-To: <20200218181718.7258-1-madhuparnabhowmik10@gmail.com>
On Tue, Feb 18, 2020 at 1:17 PM <madhuparnabhowmik10@gmail.com> wrote:
>
> From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
>
> list_for_each_entry_rcu() has built-in RCU and lock checking.
>
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
>
> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> ---
> net/netlabel/netlabel_unlabeled.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Not that this has much bearing since it's already been merged, but for
what it's worth ...
Acked-by: Paul Moore <paul@paul-moore.com>
> diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
> index d2e4ab8d1cb1..77bb1bb22c3b 100644
> --- a/net/netlabel/netlabel_unlabeled.c
> +++ b/net/netlabel/netlabel_unlabeled.c
> @@ -207,7 +207,8 @@ static struct netlbl_unlhsh_iface *netlbl_unlhsh_search_iface(int ifindex)
>
> bkt = netlbl_unlhsh_hash(ifindex);
> bkt_list = &netlbl_unlhsh_rcu_deref(netlbl_unlhsh)->tbl[bkt];
> - list_for_each_entry_rcu(iter, bkt_list, list)
> + list_for_each_entry_rcu(iter, bkt_list, list,
> + lockdep_is_held(&netlbl_unlhsh_lock))
> if (iter->valid && iter->ifindex == ifindex)
> return iter;
>
> --
> 2.17.1
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] netlabel_domainhash.c: Use built-in RCU list checking
From: Paul Moore @ 2020-02-18 22:50 UTC (permalink / raw)
To: madhuparnabhowmik10
Cc: davem, netdev, linux-security-module, linux-kernel, joel,
frextrite, linux-kernel-mentees, paulmck
In-Reply-To: <20200218184132.20363-1-madhuparnabhowmik10@gmail.com>
On Tue, Feb 18, 2020 at 1:42 PM <madhuparnabhowmik10@gmail.com> wrote:
>
> From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
>
> list_for_each_entry_rcu() has built-in RCU and lock checking.
>
> Pass cond argument to list_for_each_entry_rcu() to silence
> false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled
> by default.
>
> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> ---
> net/netlabel/netlabel_domainhash.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Same as with the other patch.
Acked-by: Paul Moore <paul@paul-moore.com>
> diff --git a/net/netlabel/netlabel_domainhash.c b/net/netlabel/netlabel_domainhash.c
> index f5d34da0646e..a1f2320ecc16 100644
> --- a/net/netlabel/netlabel_domainhash.c
> +++ b/net/netlabel/netlabel_domainhash.c
> @@ -143,7 +143,8 @@ static struct netlbl_dom_map *netlbl_domhsh_search(const char *domain,
> if (domain != NULL) {
> bkt = netlbl_domhsh_hash(domain);
> bkt_list = &netlbl_domhsh_rcu_deref(netlbl_domhsh)->tbl[bkt];
> - list_for_each_entry_rcu(iter, bkt_list, list)
> + list_for_each_entry_rcu(iter, bkt_list, list,
> + lockdep_is_held(&netlbl_domhsh_lock))
> if (iter->valid &&
> netlbl_family_match(iter->family, family) &&
> strcmp(iter->domain, domain) == 0)
> --
> 2.17.1
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v3 00/25] user_namespace: introduce fsid mappings
From: James Bottomley @ 2020-02-18 23:50 UTC (permalink / raw)
To: Christian Brauner, Stéphane Graber, Eric W. Biederman,
Aleksa Sarai, Jann Horn
Cc: Kees Cook, Jonathan Corbet, linux-kernel, containers, smbarber,
Seth Forshee, linux-security-module, Alexander Viro, linux-api,
linux-fsdevel, Alexey Dobriyan
In-Reply-To: <20200218143411.2389182-1-christian.brauner@ubuntu.com>
On Tue, 2020-02-18 at 15:33 +0100, Christian Brauner wrote:
> In the usual case of running an unprivileged container we will have
> setup an id mapping, e.g. 0 100000 100000. The on-disk mapping will
> correspond to this id mapping, i.e. all files which we want to appear
> as 0:0 inside the user namespace will be chowned to 100000:100000 on
> the host. This works, because whenever the kernel needs to do a
> filesystem access it will lookup the corresponding uid and gid in the
> idmapping tables of the container. Now think about the case where we
> want to have an id mapping of 0 100000 100000 but an on-disk mapping
> of 0 300000 100000 which is needed to e.g. share a single on-disk
> mapping with multiple containers that all have different id mappings.
> This will be problematic. Whenever a filesystem access is requested,
> the kernel will now try to lookup a mapping for 300000 in the id
> mapping tables of the user namespace but since there is none the
> files will appear to be owned by the overflow id, i.e. usually
> 65534:65534 or nobody:nogroup.
>
> With fsid mappings we can solve this by writing an id mapping of 0
> 100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
> access the kernel will now lookup the mapping for 300000 in the fsid
> mapping tables of the user namespace. And since such a mapping
> exists, the corresponding files will have correct ownership.
So I did compile this up in order to run the shiftfs tests over it to
see how it coped with the various corner cases. However, what I find
is it simply fails the fsid reverse mapping in the setup. Trying to
use a simple uid of 0 100000 1000 and a fsid of 100000 0 1000 fails the
entry setuid(0) call because of this code:
long __sys_setuid(uid_t uid)
{
struct user_namespace *ns =
current_user_ns();
const struct cred *old;
struct cred *new;
int
retval;
kuid_t kuid;
kuid_t kfsuid;
kuid = make_kuid(ns, uid);
if
(!uid_valid(kuid))
return -EINVAL;
kfsuid = make_kfsuid(ns, uid);
if
(!uid_valid(kfsuid))
return -EINVAL;
which means you can't have a fsid mapping that doesn't have the same
domain as the uid mapping, meaning a reverse mapping isn't possible
because the range and domain have to be inverse and disjoint.
James
^ permalink raw reply
* Re: [PATCH v3 01/25] user_namespace: introduce fsid mappings infrastructure
From: Serge E. Hallyn @ 2020-02-19 2:33 UTC (permalink / raw)
To: Christian Brauner
Cc: Stéphane Graber, Eric W. Biederman, Aleksa Sarai, Jann Horn,
smbarber, Seth Forshee, Alexander Viro, Alexey Dobriyan,
Serge Hallyn, James Morris, Kees Cook, Jonathan Corbet,
Phil Estes, linux-kernel, linux-fsdevel, containers,
linux-security-module, linux-api
In-Reply-To: <20200218143411.2389182-2-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 03:33:47PM +0100, Christian Brauner wrote:
> This introduces the infrastructure to setup fsid mappings which will be used in
> later patches.
> All new code depends on CONFIG_USER_NS_FSID=y. It currently defaults to "N".
> If CONFIG_USER_NS_FSID is not set, no new code is added.
>
> In this patch fsuid_m_show() and fsgid_m_show() are introduced. They are
> identical to uid_m_show() and gid_m_show() until we introduce from_kfsuid() and
> from_kfsgid() in a follow-up patch.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
> ---
> /* v2 */
> - Randy Dunlap <rdunlap@infradead.org>:
> - Fix typo in USER_NS_FSID kconfig documentation.
>
> /* v3 */
> unchanged
> ---
> include/linux/user_namespace.h | 10 +++
> init/Kconfig | 11 +++
> kernel/user.c | 22 ++++++
> kernel/user_namespace.c | 122 +++++++++++++++++++++++++++++++++
> 4 files changed, 165 insertions(+)
>
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index 6ef1c7109fc4..e44742b0cf8a 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -56,6 +56,10 @@ enum ucount_type {
> struct user_namespace {
> struct uid_gid_map uid_map;
> struct uid_gid_map gid_map;
> +#ifdef CONFIG_USER_NS_FSID
> + struct uid_gid_map fsuid_map;
> + struct uid_gid_map fsgid_map;
> +#endif
> struct uid_gid_map projid_map;
> atomic_t count;
> struct user_namespace *parent;
> @@ -127,6 +131,12 @@ struct seq_operations;
> extern const struct seq_operations proc_uid_seq_operations;
> extern const struct seq_operations proc_gid_seq_operations;
> extern const struct seq_operations proc_projid_seq_operations;
> +#ifdef CONFIG_USER_NS_FSID
> +extern const struct seq_operations proc_fsuid_seq_operations;
> +extern const struct seq_operations proc_fsgid_seq_operations;
> +extern ssize_t proc_fsuid_map_write(struct file *, const char __user *, size_t, loff_t *);
> +extern ssize_t proc_fsgid_map_write(struct file *, const char __user *, size_t, loff_t *);
> +#endif
> extern ssize_t proc_uid_map_write(struct file *, const char __user *, size_t, loff_t *);
> extern ssize_t proc_gid_map_write(struct file *, const char __user *, size_t, loff_t *);
> extern ssize_t proc_projid_map_write(struct file *, const char __user *, size_t, loff_t *);
> diff --git a/init/Kconfig b/init/Kconfig
> index cfee56c151f1..d4d0beeba48f 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1111,6 +1111,17 @@ config USER_NS
>
> If unsure, say N.
>
> +config USER_NS_FSID
> + bool "User namespace fsid mappings"
> + depends on USER_NS
> + default n
> + help
> + This allows containers to alter their filesystem id mappings.
> + With this containers with different id mappings can still share
> + the same filesystem.
> +
> + If unsure, say N.
> +
> config PID_NS
> bool "PID Namespaces"
> default y
> diff --git a/kernel/user.c b/kernel/user.c
> index 5235d7f49982..2ccaea9b810b 100644
> --- a/kernel/user.c
> +++ b/kernel/user.c
> @@ -55,6 +55,28 @@ struct user_namespace init_user_ns = {
> },
> },
> },
> +#ifdef CONFIG_USER_NS_FSID
> + .fsuid_map = {
> + .nr_extents = 1,
> + {
> + .extent[0] = {
> + .first = 0,
> + .lower_first = 0,
> + .count = 4294967295U,
> + },
> + },
> + },
> + .fsgid_map = {
> + .nr_extents = 1,
> + {
> + .extent[0] = {
> + .first = 0,
> + .lower_first = 0,
> + .count = 4294967295U,
> + },
> + },
> + },
> +#endif
> .count = ATOMIC_INIT(3),
> .owner = GLOBAL_ROOT_UID,
> .group = GLOBAL_ROOT_GID,
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index 8eadadc478f9..cbdf456f95f0 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -191,6 +191,16 @@ static void free_user_ns(struct work_struct *work)
> kfree(ns->projid_map.forward);
> kfree(ns->projid_map.reverse);
> }
> +#ifdef CONFIG_USER_NS_FSID
> + if (ns->fsgid_map.nr_extents > UID_GID_MAP_MAX_BASE_EXTENTS) {
> + kfree(ns->fsgid_map.forward);
> + kfree(ns->fsgid_map.reverse);
> + }
> + if (ns->fsuid_map.nr_extents > UID_GID_MAP_MAX_BASE_EXTENTS) {
> + kfree(ns->fsuid_map.forward);
> + kfree(ns->fsuid_map.reverse);
> + }
> +#endif
> retire_userns_sysctls(ns);
> key_free_user_ns(ns);
> ns_free_inum(&ns->ns);
> @@ -637,6 +647,50 @@ static int projid_m_show(struct seq_file *seq, void *v)
> return 0;
> }
>
> +#ifdef CONFIG_USER_NS_FSID
> +static int fsuid_m_show(struct seq_file *seq, void *v)
> +{
> + struct user_namespace *ns = seq->private;
> + struct uid_gid_extent *extent = v;
> + struct user_namespace *lower_ns;
> + uid_t lower;
> +
> + lower_ns = seq_user_ns(seq);
> + if ((lower_ns == ns) && lower_ns->parent)
> + lower_ns = lower_ns->parent;
> +
> + lower = from_kuid(lower_ns, KUIDT_INIT(extent->lower_first));
> +
> + seq_printf(seq, "%10u %10u %10u\n",
> + extent->first,
> + lower,
> + extent->count);
> +
> + return 0;
> +}
> +
> +static int fsgid_m_show(struct seq_file *seq, void *v)
> +{
> + struct user_namespace *ns = seq->private;
> + struct uid_gid_extent *extent = v;
> + struct user_namespace *lower_ns;
> + gid_t lower;
> +
> + lower_ns = seq_user_ns(seq);
> + if ((lower_ns == ns) && lower_ns->parent)
> + lower_ns = lower_ns->parent;
> +
> + lower = from_kgid(lower_ns, KGIDT_INIT(extent->lower_first));
> +
> + seq_printf(seq, "%10u %10u %10u\n",
> + extent->first,
> + lower,
> + extent->count);
> +
> + return 0;
> +}
> +#endif
> +
> static void *m_start(struct seq_file *seq, loff_t *ppos,
> struct uid_gid_map *map)
> {
> @@ -674,6 +728,22 @@ static void *projid_m_start(struct seq_file *seq, loff_t *ppos)
> return m_start(seq, ppos, &ns->projid_map);
> }
>
> +#ifdef CONFIG_USER_NS_FSID
> +static void *fsuid_m_start(struct seq_file *seq, loff_t *ppos)
> +{
> + struct user_namespace *ns = seq->private;
> +
> + return m_start(seq, ppos, &ns->fsuid_map);
> +}
> +
> +static void *fsgid_m_start(struct seq_file *seq, loff_t *ppos)
> +{
> + struct user_namespace *ns = seq->private;
> +
> + return m_start(seq, ppos, &ns->fsgid_map);
> +}
> +#endif
> +
> static void *m_next(struct seq_file *seq, void *v, loff_t *pos)
> {
> (*pos)++;
> @@ -706,6 +776,22 @@ const struct seq_operations proc_projid_seq_operations = {
> .show = projid_m_show,
> };
>
> +#ifdef CONFIG_USER_NS_FSID
> +const struct seq_operations proc_fsuid_seq_operations = {
> + .start = fsuid_m_start,
> + .stop = m_stop,
> + .next = m_next,
> + .show = fsuid_m_show,
> +};
> +
> +const struct seq_operations proc_fsgid_seq_operations = {
> + .start = fsgid_m_start,
> + .stop = m_stop,
> + .next = m_next,
> + .show = fsgid_m_show,
> +};
> +#endif
> +
> static bool mappings_overlap(struct uid_gid_map *new_map,
> struct uid_gid_extent *extent)
> {
> @@ -1081,6 +1167,42 @@ ssize_t proc_projid_map_write(struct file *file, const char __user *buf,
> &ns->projid_map, &ns->parent->projid_map);
> }
>
> +#ifdef CONFIG_USER_NS_FSID
> +ssize_t proc_fsuid_map_write(struct file *file, const char __user *buf,
> + size_t size, loff_t *ppos)
> +{
> + struct seq_file *seq = file->private_data;
> + struct user_namespace *ns = seq->private;
> + struct user_namespace *seq_ns = seq_user_ns(seq);
> +
> + if (!ns->parent)
> + return -EPERM;
> +
> + if ((seq_ns != ns) && (seq_ns != ns->parent))
> + return -EPERM;
> +
> + return map_write(file, buf, size, ppos, CAP_SETUID, &ns->fsuid_map,
> + &ns->parent->fsuid_map);
> +}
> +
> +ssize_t proc_fsgid_map_write(struct file *file, const char __user *buf,
> + size_t size, loff_t *ppos)
> +{
> + struct seq_file *seq = file->private_data;
> + struct user_namespace *ns = seq->private;
> + struct user_namespace *seq_ns = seq_user_ns(seq);
> +
> + if (!ns->parent)
> + return -EPERM;
> +
> + if ((seq_ns != ns) && (seq_ns != ns->parent))
> + return -EPERM;
> +
> + return map_write(file, buf, size, ppos, CAP_SETGID, &ns->fsgid_map,
> + &ns->parent->fsgid_map);
> +}
> +#endif
> +
> static bool new_idmap_permitted(const struct file *file,
> struct user_namespace *ns, int cap_setid,
> struct uid_gid_map *new_map)
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH v3 02/25] proc: add /proc/<pid>/fsuid_map
From: Serge E. Hallyn @ 2020-02-19 2:33 UTC (permalink / raw)
To: Christian Brauner
Cc: Stéphane Graber, Eric W. Biederman, Aleksa Sarai, Jann Horn,
smbarber, Seth Forshee, Alexander Viro, Alexey Dobriyan,
Serge Hallyn, James Morris, Kees Cook, Jonathan Corbet,
Phil Estes, linux-kernel, linux-fsdevel, containers,
linux-security-module, linux-api
In-Reply-To: <20200218143411.2389182-3-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 03:33:48PM +0100, Christian Brauner wrote:
> The /proc/<pid>/fsuid_map file can be written once to setup an fsuid mapping
> for a user namespace. Writing to this file has the same restrictions as writing
> to /proc/<pid>/fsuid_map:
>
> root@e1-vm:/# cat /proc/13023/fsuid_map
> 0 300000 100000
>
> Fsid mappings have always been around. They are currently always identical to
> the id mappings for a user namespace. This means, currently whenever an fsid
> needs to be looked up the kernel will use the id mapping of the user namespace.
> With the introduction of fsid mappings the kernel will now lookup fsids in the
> fsid mappings of the user namespace. If no fsid mapping exists the kernel will
> continue looking up fsids in the id mappings of the user namespace. Hence, if a
> system supports fsid mappings through /proc/<pid>/fs*id_map and a container
> runtime is not aware of fsid mappings it or does not use them it will it will
> continue to work just as before.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
> ---
> /* v2 */
> unchanged
>
> /* v3 */
> - Christian Brauner <christian.brauner@ubuntu.com>:
> - Fix grammar in commit message.
> ---
> fs/proc/base.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c7c64272b0fa..5fb28004663e 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2970,6 +2970,13 @@ static int proc_projid_map_open(struct inode *inode, struct file *file)
> return proc_id_map_open(inode, file, &proc_projid_seq_operations);
> }
>
> +#ifdef CONFIG_USER_NS_FSID
> +static int proc_fsuid_map_open(struct inode *inode, struct file *file)
> +{
> + return proc_id_map_open(inode, file, &proc_fsuid_seq_operations);
> +}
> +#endif
> +
> static const struct file_operations proc_uid_map_operations = {
> .open = proc_uid_map_open,
> .write = proc_uid_map_write,
> @@ -2994,6 +3001,16 @@ static const struct file_operations proc_projid_map_operations = {
> .release = proc_id_map_release,
> };
>
> +#ifdef CONFIG_USER_NS_FSID
> +static const struct file_operations proc_fsuid_map_operations = {
> + .open = proc_fsuid_map_open,
> + .write = proc_fsuid_map_write,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = proc_id_map_release,
> +};
> +#endif
> +
> static int proc_setgroups_open(struct inode *inode, struct file *file)
> {
> struct user_namespace *ns = NULL;
> @@ -3176,6 +3193,9 @@ static const struct pid_entry tgid_base_stuff[] = {
> ONE("io", S_IRUSR, proc_tgid_io_accounting),
> #endif
> #ifdef CONFIG_USER_NS
> +#ifdef CONFIG_USER_NS_FSID
> + REG("fsuid_map", S_IRUGO|S_IWUSR, proc_fsuid_map_operations),
> +#endif
> REG("uid_map", S_IRUGO|S_IWUSR, proc_uid_map_operations),
> REG("gid_map", S_IRUGO|S_IWUSR, proc_gid_map_operations),
> REG("projid_map", S_IRUGO|S_IWUSR, proc_projid_map_operations),
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH v3 03/25] proc: add /proc/<pid>/fsgid_map
From: Serge E. Hallyn @ 2020-02-19 2:33 UTC (permalink / raw)
To: Christian Brauner
Cc: Stéphane Graber, Eric W. Biederman, Aleksa Sarai, Jann Horn,
smbarber, Seth Forshee, Alexander Viro, Alexey Dobriyan,
Serge Hallyn, James Morris, Kees Cook, Jonathan Corbet,
Phil Estes, linux-kernel, linux-fsdevel, containers,
linux-security-module, linux-api
In-Reply-To: <20200218143411.2389182-4-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 03:33:49PM +0100, Christian Brauner wrote:
> The /proc/<pid>/fsgid_map file can be written once to setup an fsgid mapping
> for a user namespace. Writing to this file has the same restrictions as writing
> to /proc/<pid>/fsgid_map.
>
> root@e1-vm:/# cat /proc/13023/fsgid_map
> 0 300000 100000
>
> Fsid mappings have always been around. They are currently always identical to
> the id mappings for a user namespace. This means, currently whenever an fsid
> needs to be looked up the kernel will use the id mapping of the user namespace.
> With the introduction of fsid mappings the kernel will now lookup fsids in the
> fsid mappings of the user namespace. If no fsid mapping exists the kernel will
> continue looking up fsids in the id mappings of the user namespace. Hence, if a
> system supports fsid mappings through /proc/<pid>/fs*id_map and a container
> runtime is not aware of fsid mappings it or does not use them it will it will
> continue to work just as before.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
> ---
> /* v2 */
> unchanged
>
> /* v3 */
> - Christian Brauner <christian.brauner@ubuntu.com>:
> - Fix grammar in commit message.
> ---
> fs/proc/base.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 5fb28004663e..1303cdd2e617 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2975,6 +2975,11 @@ static int proc_fsuid_map_open(struct inode *inode, struct file *file)
> {
> return proc_id_map_open(inode, file, &proc_fsuid_seq_operations);
> }
> +
> +static int proc_fsgid_map_open(struct inode *inode, struct file *file)
> +{
> + return proc_id_map_open(inode, file, &proc_fsgid_seq_operations);
> +}
> #endif
>
> static const struct file_operations proc_uid_map_operations = {
> @@ -3009,6 +3014,14 @@ static const struct file_operations proc_fsuid_map_operations = {
> .llseek = seq_lseek,
> .release = proc_id_map_release,
> };
> +
> +static const struct file_operations proc_fsgid_map_operations = {
> + .open = proc_fsgid_map_open,
> + .write = proc_fsgid_map_write,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = proc_id_map_release,
> +};
> #endif
>
> static int proc_setgroups_open(struct inode *inode, struct file *file)
> @@ -3195,6 +3208,7 @@ static const struct pid_entry tgid_base_stuff[] = {
> #ifdef CONFIG_USER_NS
> #ifdef CONFIG_USER_NS_FSID
> REG("fsuid_map", S_IRUGO|S_IWUSR, proc_fsuid_map_operations),
> + REG("fsgid_map", S_IRUGO|S_IWUSR, proc_fsgid_map_operations),
> #endif
> REG("uid_map", S_IRUGO|S_IWUSR, proc_uid_map_operations),
> REG("gid_map", S_IRUGO|S_IWUSR, proc_gid_map_operations),
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH v3 05/25] user_namespace: refactor map_write()
From: Serge E. Hallyn @ 2020-02-19 2:35 UTC (permalink / raw)
To: Christian Brauner
Cc: Stéphane Graber, Eric W. Biederman, Aleksa Sarai, Jann Horn,
smbarber, Seth Forshee, Alexander Viro, Alexey Dobriyan,
Serge Hallyn, James Morris, Kees Cook, Jonathan Corbet,
Phil Estes, linux-kernel, linux-fsdevel, containers,
linux-security-module, linux-api
In-Reply-To: <20200218143411.2389182-6-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 03:33:51PM +0100, Christian Brauner wrote:
> Refactor map_write() to prepare for adding fsid mappings support. This mainly
> factors out various open-coded parts into helpers that can be reused in the
> follow up patch.
>
> Cc: Jann Horn <jannh@google.com>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
> ---
> /* v2 */
> patch not present
>
> /* v3 */
> patch added
> - Jann Horn <jannh@google.com>:
> - Split changes to map_write() to implement fsid mappings into three separate
> patches: basic fsid helpers, preparatory changes to map_write(), actual
> fsid mapping support in map_write().
> ---
> kernel/user_namespace.c | 117 +++++++++++++++++++++++++---------------
> 1 file changed, 74 insertions(+), 43 deletions(-)
>
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index 2cfd1e519cc4..e91141262bcc 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -1038,10 +1038,10 @@ static int cmp_extents_reverse(const void *a, const void *b)
> }
>
> /**
> - * sort_idmaps - Sorts an array of idmap entries.
> + * sort_map - Sorts an array of idmap entries.
> * Can only be called if number of mappings exceeds UID_GID_MAP_MAX_BASE_EXTENTS.
> */
> -static int sort_idmaps(struct uid_gid_map *map)
> +static int sort_map(struct uid_gid_map *map)
> {
> if (map->nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS)
> return 0;
> @@ -1064,6 +1064,71 @@ static int sort_idmaps(struct uid_gid_map *map)
> return 0;
> }
>
> +static int sort_idmaps(struct uid_gid_map *map)
> +{
> + return sort_map(map);
> +}
> +
> +static int map_from_parent(struct uid_gid_map *new_map,
> + struct uid_gid_map *parent_map)
> +{
> + unsigned idx;
> +
> + /* Map the lower ids from the parent user namespace to the
> + * kernel global id space.
> + */
> + for (idx = 0; idx < new_map->nr_extents; idx++) {
> + struct uid_gid_extent *e;
> + u32 lower_first;
> +
> + if (new_map->nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS)
> + e = &new_map->extent[idx];
> + else
> + e = &new_map->forward[idx];
> +
> + lower_first = map_id_range_down(parent_map, e->lower_first, e->count);
> +
> + /* Fail if we can not map the specified extent to
> + * the kernel global id space.
> + */
> + if (lower_first == (u32)-1)
> + return -EPERM;
> +
> + e->lower_first = lower_first;
> + }
> +
> + return 0;
> +}
> +
> +static int map_into_kids(struct uid_gid_map *id_map,
> + struct uid_gid_map *parent_id_map)
> +{
> + return map_from_parent(id_map, parent_id_map);
> +}
> +
> +static void install_idmaps(struct uid_gid_map *id_map,
> + struct uid_gid_map *new_id_map)
> +{
> + if (new_id_map->nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS) {
> + memcpy(id_map->extent, new_id_map->extent,
> + new_id_map->nr_extents * sizeof(new_id_map->extent[0]));
> + } else {
> + id_map->forward = new_id_map->forward;
> + id_map->reverse = new_id_map->reverse;
> + }
> +}
> +
> +static void free_idmaps(struct uid_gid_map *new_id_map)
> +{
> + if (new_id_map->nr_extents > UID_GID_MAP_MAX_BASE_EXTENTS) {
> + kfree(new_id_map->forward);
> + kfree(new_id_map->reverse);
> + new_id_map->forward = NULL;
> + new_id_map->reverse = NULL;
> + new_id_map->nr_extents = 0;
> + }
> +}
> +
> static ssize_t map_write(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos,
> int cap_setid,
> @@ -1073,7 +1138,6 @@ static ssize_t map_write(struct file *file, const char __user *buf,
> struct seq_file *seq = file->private_data;
> struct user_namespace *ns = seq->private;
> struct uid_gid_map new_map;
> - unsigned idx;
> struct uid_gid_extent extent;
> char *kbuf = NULL, *pos, *next_line;
> ssize_t ret;
> @@ -1191,61 +1255,28 @@ static ssize_t map_write(struct file *file, const char __user *buf,
> if (!new_idmap_permitted(file, ns, cap_setid, &new_map))
> goto out;
>
> - ret = -EPERM;
> - /* Map the lower ids from the parent user namespace to the
> - * kernel global id space.
> - */
> - for (idx = 0; idx < new_map.nr_extents; idx++) {
> - struct uid_gid_extent *e;
> - u32 lower_first;
> -
> - if (new_map.nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS)
> - e = &new_map.extent[idx];
> - else
> - e = &new_map.forward[idx];
> -
> - lower_first = map_id_range_down(parent_map,
> - e->lower_first,
> - e->count);
> -
> - /* Fail if we can not map the specified extent to
> - * the kernel global id space.
> - */
> - if (lower_first == (u32) -1)
> - goto out;
> -
> - e->lower_first = lower_first;
> - }
> + ret = map_into_kids(&new_map, parent_map);
> + if (ret)
> + goto out;
>
> /*
> * If we want to use binary search for lookup, this clones the extent
> * array and sorts both copies.
> */
> ret = sort_idmaps(&new_map);
> - if (ret < 0)
> + if (ret)
> goto out;
>
> /* Install the map */
> - if (new_map.nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS) {
> - memcpy(map->extent, new_map.extent,
> - new_map.nr_extents * sizeof(new_map.extent[0]));
> - } else {
> - map->forward = new_map.forward;
> - map->reverse = new_map.reverse;
> - }
> + install_idmaps(map, &new_map);
> smp_wmb();
> map->nr_extents = new_map.nr_extents;
>
> *ppos = count;
> ret = count;
> out:
> - if (ret < 0 && new_map.nr_extents > UID_GID_MAP_MAX_BASE_EXTENTS) {
> - kfree(new_map.forward);
> - kfree(new_map.reverse);
> - map->forward = NULL;
> - map->reverse = NULL;
> - map->nr_extents = 0;
> - }
> + if (ret < 0)
> + free_idmaps(&new_map);
>
> mutex_unlock(&userns_state_mutex);
> kfree(kbuf);
> --
> 2.25.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox