All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [GIT PULL] user namespace and namespace infrastructure changes for 3.8
Date: Fri, 14 Dec 2012 09:48:54 -0800	[thread overview]
Message-ID: <87vcc47ce1.fsf@xmission.com> (raw)
In-Reply-To: <CALCETrXagfjy4o0_JCZpMfdocYK-MpOp3eH-tPZhgazvJAy-EQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Andy Lutomirski's message of "Thu, 13 Dec 2012 21:34:22 -0800")

Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:

> On Thu, Dec 13, 2012 at 8:11 PM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
>>
>>> One more issue: the requirement that both upper and lower uids (etc.)
>>> in the maps are in order is rather limiting.  I have no objection if
>>> you only require upper ids to be monotonic, but currently there's no
>>> way to may root outside to uid n (for n > 0) and some nonroot user
>>> outside to uid 0.
>>
>> There is.  You may set up to 5 (extents).  You just have to use a second
>> extent for the non-contiguous bits.  My reader is lazy and you have to
>> set all of the extents with a single write, so you may have missed the
>> ability to set more than one extent.
>>
>
> If I'm wrong, I'll happily eat my words.  Both:
>
> 0 1 1
> 1 0 1
>
> and
>
> 1 0 1
> 0 1 1
>
> are rejected, unless I totally messed up.

Duh.  You are right.  

It is this check:

		/* For now only accept extents that are strictly in order */
		if (last &&
		    (((last->first + last->count) > extent->first) ||
		     ((last->lower_first + last->count) > extent->lower_first)))
			goto out;

Fundamentally every value mapped must be distinct.  Aka the direction of
the mapping must be reversible without loss of information.  

Ensuring all of the values were increasing in the extents was just a
lame way of ensuring that the same value was not mapped twice in either
the upper or lower ranges.

That check can most certainly be relaxed (patches welcome).  But that
probably isn't 3.8 material as that is feature work.

Not having bumped into this limitation myself I'm not certain the value
in removing this check.  But there is no good reason not to replace the
current check with a more general one either.

So your example should work, and that it doesn't is a misfeature.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	containers@lists.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] user namespace and namespace infrastructure changes for 3.8
Date: Fri, 14 Dec 2012 09:48:54 -0800	[thread overview]
Message-ID: <87vcc47ce1.fsf@xmission.com> (raw)
In-Reply-To: <CALCETrXagfjy4o0_JCZpMfdocYK-MpOp3eH-tPZhgazvJAy-EQ@mail.gmail.com> (Andy Lutomirski's message of "Thu, 13 Dec 2012 21:34:22 -0800")

Andy Lutomirski <luto@amacapital.net> writes:

> On Thu, Dec 13, 2012 at 8:11 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> One more issue: the requirement that both upper and lower uids (etc.)
>>> in the maps are in order is rather limiting.  I have no objection if
>>> you only require upper ids to be monotonic, but currently there's no
>>> way to may root outside to uid n (for n > 0) and some nonroot user
>>> outside to uid 0.
>>
>> There is.  You may set up to 5 (extents).  You just have to use a second
>> extent for the non-contiguous bits.  My reader is lazy and you have to
>> set all of the extents with a single write, so you may have missed the
>> ability to set more than one extent.
>>
>
> If I'm wrong, I'll happily eat my words.  Both:
>
> 0 1 1
> 1 0 1
>
> and
>
> 1 0 1
> 0 1 1
>
> are rejected, unless I totally messed up.

Duh.  You are right.  

It is this check:

		/* For now only accept extents that are strictly in order */
		if (last &&
		    (((last->first + last->count) > extent->first) ||
		     ((last->lower_first + last->count) > extent->lower_first)))
			goto out;

Fundamentally every value mapped must be distinct.  Aka the direction of
the mapping must be reversible without loss of information.  

Ensuring all of the values were increasing in the extents was just a
lame way of ensuring that the same value was not mapped twice in either
the upper or lower ranges.

That check can most certainly be relaxed (patches welcome).  But that
probably isn't 3.8 material as that is feature work.

Not having bumped into this limitation myself I'm not certain the value
in removing this check.  But there is no good reason not to replace the
current check with a more general one either.

So your example should work, and that it doesn't is a misfeature.

Eric


  parent reply	other threads:[~2012-12-14 17:48 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 21:17 [GIT PULL] user namespace and namespace infrastructure changes for 3.8 Eric W. Biederman
2012-12-11 21:17 ` Eric W. Biederman
     [not found] ` <87ip88uw4n.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-13 19:24   ` Andy Lutomirski
2012-12-13 19:24     ` Andy Lutomirski
     [not found]     ` <50CA2B55.5070402-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2012-12-13 22:01       ` Eric W. Biederman
2012-12-13 22:01         ` Eric W. Biederman
2012-12-13 22:39         ` [RFC][PATCH] Fix cap_capable to only allow owners in the parent user namespace to have caps Eric W. Biederman
2012-12-13 23:21           ` Andy Lutomirski
2012-12-14  2:33             ` Eric W. Biederman
2012-12-14  2:36               ` Andy Lutomirski
     [not found]                 ` <CALCETrXRYOh2tkwB+U9ZjA5BNZwscWsq1WGzjP3wUiOXQUXOQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14  3:20                   ` [PATCH] " Eric W. Biederman
2012-12-14  3:20                 ` Eric W. Biederman
     [not found]               ` <876245jrbc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14  2:36                 ` [RFC][PATCH] " Andy Lutomirski
     [not found]             ` <CALCETrXLLcUu8Rajjx7+3N_6j5E0T0CR1h=hD+gcc5_r4Umyqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14  2:33               ` Eric W. Biederman
     [not found]           ` <87zk1hshk7.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-13 22:43             ` Linus Torvalds
2012-12-13 22:43               ` Linus Torvalds
     [not found]               ` <CA+55aFwXnFEFXbkwFPq9xt30xp2_6jfpBLd3E2bms79KKK=V1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-13 22:55                 ` Eric W. Biederman
2012-12-13 22:55               ` Eric W. Biederman
2012-12-13 23:21             ` Andy Lutomirski
2012-12-14  3:28             ` Serge E. Hallyn
2012-12-14  3:28           ` Serge E. Hallyn
     [not found]             ` <20121214032820.GA5115-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14  3:32               ` Eric W. Biederman
2012-12-14  3:32                 ` Eric W. Biederman
     [not found]                 ` <87bodxi9zw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 15:26                   ` Serge E. Hallyn
2012-12-14 15:26                     ` Serge E. Hallyn
     [not found]                     ` <20121214152607.GA9266-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14 15:47                       ` Eric W. Biederman
2012-12-14 15:47                     ` Eric W. Biederman
     [not found]                       ` <87bodwd4aw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 16:15                         ` Serge E. Hallyn
2012-12-14 16:15                           ` Serge E. Hallyn
     [not found]                           ` <20121214161514.GA9962-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14 18:12                             ` Eric W. Biederman
2012-12-14 18:12                               ` Eric W. Biederman
     [not found]                               ` <87r4ms5wpm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14 18:43                                 ` Linus Torvalds
2012-12-14 18:43                                   ` Linus Torvalds
2012-12-14 18:47                                   ` Andy Lutomirski
     [not found]                                   ` <CA+55aFw5CMf0-o=yDt2Rj-SYH4pfW1L9QbNb6uKHEdzAyYcvGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14 18:47                                     ` Andy Lutomirski
2012-12-14 20:50                                     ` Serge E. Hallyn
2012-12-14 21:43                                     ` Eric W. Biederman
2012-12-14 20:50                                   ` Serge E. Hallyn
2012-12-14 21:43                                   ` Eric W. Biederman
2012-12-14 20:29                                 ` Serge E. Hallyn
2012-12-14 20:29                               ` Serge E. Hallyn
     [not found]                                 ` <20121214202921.GA11450-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-12-14 22:32                                   ` Eric W. Biederman
2012-12-14 22:32                                     ` Eric W. Biederman
     [not found]                                     ` <87bodww9hv.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-15  0:14                                       ` Serge E. Hallyn
2012-12-15  0:14                                     ` Serge E. Hallyn
     [not found]         ` <87mwxhtxve.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-13 22:39           ` Eric W. Biederman
2012-12-13 23:02           ` [GIT PULL] user namespace and namespace infrastructure changes for 3.8 Andy Lutomirski
2012-12-13 23:02             ` Andy Lutomirski
     [not found]             ` <CALCETrWxXZ1OzZeH_SGeg1E16rssxBwg+hjG09N5dkqweVKeRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14  4:11               ` Eric W. Biederman
2012-12-14  4:11                 ` Eric W. Biederman
     [not found]                 ` <87mwxhff2e.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-14  5:34                   ` Andy Lutomirski
2012-12-14  5:34                     ` Andy Lutomirski
     [not found]                     ` <CALCETrXagfjy4o0_JCZpMfdocYK-MpOp3eH-tPZhgazvJAy-EQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-14 17:48                       ` Eric W. Biederman [this message]
2012-12-14 17:48                         ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2012-12-17 23:18 Eric W. Biederman
2012-12-17 23:18 Eric W. Biederman
     [not found] ` <87wqwggtcu.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-18  7:47   ` Eric W. Biederman
2012-12-18  7:47     ` Eric W. Biederman
2012-12-21  7:05   ` Rob Landley
2012-12-21  7:05     ` Rob Landley
2012-12-21  7:47     ` Eric W. Biederman
2012-12-21  7:47       ` Eric W. Biederman

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=87vcc47ce1.fsf@xmission.com \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    /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.