All of lore.kernel.org
 help / color / mirror / Atom feed
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?


  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.