From: Andrew Morton <akpm@linux-foundation.org>
To: Aristeu Rozanski <aris@redhat.com>
Cc: linux-kernel@vger.kernel.org,
"Serge E. Hallyn" <serge@hallyn.com>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v2] userns: improve uid/gid map collision detection
Date: Thu, 24 Jan 2013 16:46:12 -0800 [thread overview]
Message-ID: <20130124164612.af6de6f3.akpm@linux-foundation.org> (raw)
In-Reply-To: <20130124152859.GP17632@redhat.com>
On Thu, 24 Jan 2013 10:28:59 -0500
Aristeu Rozanski <aris@redhat.com> wrote:
> userns: improve uid/gid map collision detection
>
> Initial implementation of the uid/gid maps (/proc/<pid>/{u,g}id_map) will
> enforce that the UID and GID maps be written in strict order as a simple
> way to check for range collision:
> local id mapped to count/range
> 0 1000 50
> (ids 0-50 get mapped to 1000-1050)
> 100 2120 10
> 500 5000 200
> so for each new entry, local id must be bigger than last local id (plus
> count) and the ids it maps to also needs to be bigger than the last
> entry (plus count).
>
> This makes impossible to have a use case like this:
> local id mapped to count/range
> 0 1000 1
> 48 500 20
>
> because while 48+20 > 0+1, 500+20 < 1000+1.
>
> This patch implements a more elaborate collision detection allowing any
> order to be used.
>
> v2: improved the patch description as requested by Andrew
Thanks.
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -521,6 +521,28 @@ struct seq_operations proc_projid_seq_operations = {
>
> static DEFINE_MUTEX(id_map_mutex);
>
> +#define in_range(b,first,len) ((b)>=(first)&&(b)<(first)+(len))
eek, a macro! Macros are always bad.
This one is bad because
a) it's a macro
b) it evaluates its args multiple times and hence will cause nasty
bugs if called with expressions-with-side-effects.
c) it evaluates its args multiple times and if called with
non-trivial expressions the compiler might not be able to CSE those
expressions, leading to code bloat.
Add lo, this patch:
--- a/kernel/user_namespace.c~userns-improve-uid-gid-map-collision-detection-fix
+++ a/kernel/user_namespace.c
@@ -521,7 +521,11 @@ struct seq_operations proc_projid_seq_op
static DEFINE_MUTEX(id_map_mutex);
-#define in_range(b,first,len) ((b)>=(first)&&(b)<(first)+(len))
+static bool in_range(u32 b, u32 first, u32 len)
+{
+ return b >= first && b < first + len;
+}
+
static inline int extent_collision(struct uid_gid_map *new_map,
struct uid_gid_extent *extent)
{
reduces the user_namespace.o text from 4822 bytes to 4727 with
gcc-4.4.4. This is a remarkably large difference.
btw, what the heck is up with CONFIG_UIDGID_CONVERTED? That thing
prevents userns from being compiled in an allmodconfig build, which is
rather undesirable. Isn't there a better, more user-friendly way of
doing this?
next prev parent reply other threads:[~2013-01-25 0:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 16:02 [PATCH] userns: improve uid/gid map collision detection Aristeu Rozanski
2013-01-24 4:44 ` Serge E. Hallyn
2013-01-24 15:28 ` [PATCH v2] " Aristeu Rozanski
2013-01-25 0:46 ` Andrew Morton [this message]
2013-01-25 2:00 ` Eric W. Biederman
2013-01-25 14:03 ` Aristeu Rozanski
2013-01-26 2:31 ` Eric W. Biederman
2013-01-28 14:25 ` Aristeu Rozanski
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=20130124164612.af6de6f3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=aris@redhat.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.com \
/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: link
Be 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.