Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1201013 > unrolled thread

Re: [PATCH] user_ns: use correct check for single-threadedness

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] user_ns: use correct check for single-threadedness Oleg Nesterov <oleg@redhat.com> - 2015-08-05 19:30 +0200
    Re: [PATCH] user_ns: use correct check for single-threadedness ebiederm@xmission.com (Eric W. Biederman) - 2015-08-05 20:10 +0200
      Re: [PATCH] user_ns: use correct check for single-threadedness ebiederm@xmission.com (Eric W. Biederman) - 2015-08-05 21:00 +0200
        Re: [PATCH] user_ns: use correct check for single-threadedness Oleg Nesterov <oleg@redhat.com> - 2015-08-06 16:10 +0200
          [PATCH 0/2] userns: Creation logic fixes ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 03:30 +0200
            [PATCH 2/2] userns,pidns: Force thread group sharing, not signal handler sharing ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 03:40 +0200
              Re: [PATCH 2/2] userns,pidns: Force thread group sharing, not  signal handler sharing Oleg Nesterov <oleg@redhat.com> - 2015-08-12 19:30 +0200
            [PATCH 1/2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 03:40 +0200
              Re: [PATCH 1/2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-12 20:00 +0200
                Re: [PATCH 1/2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 20:50 +0200
                  Re: [PATCH 1/2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-13 15:00 +0200
                    Re: [PATCH 1/2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-13 17:50 +0200
                      Re: [PATCH 1/2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-13 18:20 +0200
                        Re: [PATCH 1/2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-13 18:40 +0200
                          Re: [PATCH 1/2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-13 19:00 +0200
                            Re: [PATCH 1/2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-14 20:10 +0200
                [PATCH v2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 22:10 +0200
                  Re: [PATCH v2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-13 15:00 +0200
                    Re: [PATCH v2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-13 18:10 +0200
                      Re: [PATCH v2] unshare: Unsharing a thread does not require  unsharing a vm Oleg Nesterov <oleg@redhat.com> - 2015-08-13 18:40 +0200
                        Re: [PATCH v2] unshare: Unsharing a thread does not require unsharing a vm ebiederm@xmission.com (Eric W. Biederman) - 2015-08-13 18:50 +0200
            Re: [PATCH 0/2] userns: Creation logic fixes Kees Cook <keescook@chromium.org> - 2015-08-12 08:30 +0200
          Re: [PATCH] user_ns: use correct check for single-threadedness ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 03:30 +0200
            Re: [PATCH] user_ns: use correct check for single-threadedness Oleg Nesterov <oleg@redhat.com> - 2015-08-12 16:50 +0200
              Re: [PATCH] user_ns: use correct check for single-threadedness ebiederm@xmission.com (Eric W. Biederman) - 2015-08-12 17:20 +0200
        Re: [PATCH] user_ns: use correct check for single-threadedness Oleg Nesterov <oleg@redhat.com> - 2015-08-06 17:20 +0200
          Re: [PATCH] user_ns: use correct check for single-threadedness ebiederm@xmission.com (Eric W. Biederman) - 2015-08-06 23:30 +0200
        Re: [PATCH] user_ns: use correct check for single-threadedness Oleg Nesterov <oleg@redhat.com> - 2015-08-07 04:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1206960 — Re: [PATCH v2] unshare: Unsharing a thread does not require unsharing a vm

Oleg Nesterov <oleg@redhat.com> writes:

> On 08/13, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <oleg@redhat.com> writes:
>>
>> > On 08/12, Eric W. Biederman wrote:
>> >>
>> >> +	if (unshare_flags & (CLONE_SIGHAND | CLONE_VM)) {
>> >> +		if (atomic_read(&current->sighand->count) > 1)
>> >> +			return -EINVAL;
>> >> +	}
>> >
>> > I am still not sure we want this... please the the previous email.
>>
>> Reading your other email I did not see why you thought this check was
>> unnecessary.
>>
>> > But perhaps I missed something.
>>
>> In short:
>> clone(VM) --> mm_users > 1 && sighand_struct->count == 1
>> followed by:
>> unshare(SIGHAND)
>> the unshare should succeed.
>>
>> Meanwhile:
>> clone(VM|SIGHAND) --> mm_users > 1 && sighand_struct->count > 1
>> followed by:
>> unshare(SIGHAND)
>> the unshare should fail.
>
> Yes, yes, yes.
>
> But once again, I meant we can remove this sighand->count check
> if unshare(SIGHAND) checks current_is_single_threaded(). That is
> why I suggested to do
>
> 	if (unshare_flags & CLONE_SIGHAND)
> 		unshare_flags |= CLONE_VM;
>
> in sys_unshare(), or change check_unshare_flags() to check
> "unshare_flags & (CLONE_VM | CLONE_SIGHAND)" before
> current_is_single_threaded().

See the two cases above that change to unshare_flags will make
unshare(SIGHAND) fail when sighand_struct->count == 1.

Which is fundamentally wrong.

> Damn. And this discussion makes me think that another cleanup makes
> sense too. Can't we move all these unshare_flags manipulations into
> check_unshare_flags? So that sys_unshare() will only do
>
> 	err = check_unshare_flags(&unshare_flags);
>
> and the reader of this code won't need to read 2 functions to understand
> whats going on.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205606 — Re: [PATCH 0/2] userns: Creation logic fixes

On Tue, Aug 11, 2015 at 6:22 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> So I have take a good hard stare at the problem, as well as sitting down
> and writing some test code to verify the code works the way I think it
> does.
>
> The following two patches are how I think this bit of chaos needs to be
> solved.  If folks could take a once over these patches and possibly test
> them to confirm they fix your issues I would appreciate it.
>
> Eric W. Biederman (2):
>       unshare: Unsharing a thread does not require unsharing a vm
>       userns,pidns: Force thread group sharing, not signal handler sharing.
>
>  kernel/fork.c           | 32 ++++++++++++++++++--------------
>  kernel/user_namespace.c |  4 ++--
>  2 files changed, 20 insertions(+), 16 deletions(-)

Thanks for digging into this!

Reviewed-by: Kees Cook <keescook@chromium.org>

-Kees


-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1205536

Oleg Nesterov <oleg@redhat.com> writes:

> On 08/06, Oleg Nesterov wrote:
>>
>> On 08/05, Eric W. Biederman wrote:
>> >
>> > So I have to ask.
>>
>> I hope you are asking someone else, not me ;) I never understood what
>> exactly we try to restrict and why.
>>
>> > Is it possible to rework these checks such that we
>> > look at the sighand struct and signal sharing handling sharing instead
>> > of the count on the mm_struct?
>>
>> Then why we can't simply check thread_group_empty() == T ? Why should we
>> worry about CLONE_SIGHAND at all?
>
> The same for clone() actually... I forgot why we decided to check
> CLONE_SIGHAND, iirc I suggested CLONE_THREAD initially then we switched
> to CLONE_SIGHAND "just in case", to make it as strict as possible.

I do agree that making the test be for CLONE_THREAD is safe, makes
sense, and is less confusing than what we have now.x

> How about the patch below?
>
> (note that the "or parent" part of the comment is wrong in any case).

It was correct.  You failed to removed it when you removed CLONE_PARENT
from that test.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206175

On 08/11, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> >> Then why we can't simply check thread_group_empty() == T ? Why should we
> >> worry about CLONE_SIGHAND at all?
> >
> > The same for clone() actually... I forgot why we decided to check
> > CLONE_SIGHAND, iirc I suggested CLONE_THREAD initially then we switched
> > to CLONE_SIGHAND "just in case", to make it as strict as possible.
>
> I do agree that making the test be for CLONE_THREAD is safe, makes
> sense, and is less confusing than what we have now.x

Good,

> > How about the patch below?
> >
> > (note that the "or parent" part of the comment is wrong in any case).
>
> It was correct.

Yes, I know,

> You failed to removed it when you removed CLONE_PARENT
> from that test.

Cough... it was you ;) 1f7f4dde5c945f41a7abc2285be43d918029ecc5
"fork:  Allow CLONE_PARENT after setns(CLONE_NEWPID)".

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206208

Oleg Nesterov <oleg@redhat.com> writes:

> On 08/11, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <oleg@redhat.com> writes:
>>
>> >> Then why we can't simply check thread_group_empty() == T ? Why should we
>> >> worry about CLONE_SIGHAND at all?
>> >
>> > The same for clone() actually... I forgot why we decided to check
>> > CLONE_SIGHAND, iirc I suggested CLONE_THREAD initially then we switched
>> > to CLONE_SIGHAND "just in case", to make it as strict as possible.
>>
>> I do agree that making the test be for CLONE_THREAD is safe, makes
>> sense, and is less confusing than what we have now.x
>
> Good,
>
>> > How about the patch below?
>> >
>> > (note that the "or parent" part of the comment is wrong in any case).
>>
>> It was correct.
>
> Yes, I know,
>
>> You failed to removed it when you removed CLONE_PARENT
>> from that test.
>
> Cough... it was you ;) 1f7f4dde5c945f41a7abc2285be43d918029ecc5
> "fork:  Allow CLONE_PARENT after setns(CLONE_NEWPID)".

So it was.  I must have tired when I read the git log last night.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1201838

On 08/05, Eric W. Biederman wrote:
>
> So I have to ask.

I hope you are asking someone else, not me ;) I never understood what
exactly we try to restrict and why.

> Is it possible to rework these checks such that we
> look at the sighand struct and signal sharing handling sharing instead
> of the count on the mm_struct?

Then why we can't simply check thread_group_empty() == T ? Why should we
worry about CLONE_SIGHAND at all?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202088

Oleg Nesterov <oleg@redhat.com> writes:

> On 08/05, Eric W. Biederman wrote:
>>
>> So I have to ask.
>
> I hope you are asking someone else, not me ;) I never understood what
> exactly we try to restrict and why.

I think I was just asking rhetorically, and asking myself.

>> Is it possible to rework these checks such that we
>> look at the sighand struct and signal sharing handling sharing instead
>> of the count on the mm_struct?
>
> Then why we can't simply check thread_group_empty() == T ? Why should we
> worry about CLONE_SIGHAND at all?

<rant> 
thread_group_empty() for a thread group with a single member is a
confusing name.
 </rant>

CLONE_SIGHAND is just a hair excessive, you have to at least look at
your per thread register to see which namespace to interpret the values
of the signals in.  I suppose that is confusing but not totally fatal.

Without changing the semantics, just correcting the implementation
of the code we have now this is the code I get:

diff --git a/kernel/fork.c b/kernel/fork.c
index 1bfefc6f96a4..c95757c15fcb 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1866,13 +1866,13 @@ static int check_unshare_flags(unsigned long unshare_flags)
 				CLONE_NEWUSER|CLONE_NEWPID))
 		return -EINVAL;
 	/*
-	 * Not implemented, but pretend it works if there is nothing to
-	 * unshare. Note that unsharing CLONE_THREAD or CLONE_SIGHAND
-	 * needs to unshare vm.
+	 * Not implemented, but pretend it works if there is nothing
+	 * to unshare.  Note that unsharing the address space or the
+	 * signal handlers also need to unshare the signal queues (aka
+	 * CLONE_THREAD).
 	 */
-	if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM)) {
-		/* FIXME: get_task_mm() increments ->mm_users */
-		if (atomic_read(&current->mm->mm_users) > 1)
+	if (unshare_flags & CLONE_THREAD) {
+		if (!thread_group_empty(current))
 			return -EINVAL;
 	}
 
@@ -1936,21 +1936,23 @@ SYSCALL_DEFINE1(unshare, unsigned long, unshare_flags)
 	int err;
 
 	/*
-	 * If unsharing a user namespace must also unshare the thread.
+	 * If unsharing a user namespace must also unshare the signal
+	 * handlers and unshare the filesystem root and working
+	 * directories.
 	 */
 	if (unshare_flags & CLONE_NEWUSER)
-		unshare_flags |= CLONE_THREAD | CLONE_FS;
-	/*
-	 * If unsharing a thread from a thread group, must also unshare vm.
-	 */
-	if (unshare_flags & CLONE_THREAD)
-		unshare_flags |= CLONE_VM;
+		unshare_flags |= CLONE_SIGHAND | CLONE_FS;
 	/*
 	 * If unsharing vm, must also unshare signal handlers.
 	 */
 	if (unshare_flags & CLONE_VM)
 		unshare_flags |= CLONE_SIGHAND;
 	/*
+	 * If unsharing a signal handlers, must also unshare the signal queues.
+	 */
+	if (unshare_flags & CLONE_SIGHAND)
+		unshare_flags |= CLONE_THREAD;
+	/*
 	 * If unsharing namespace, must also unshare filesystem information.
 	 */
 	if (unshare_flags & CLONE_NEWNS)
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 4109f8320684..45a5cbf97715 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -976,8 +976,8 @@ static int userns_install(struct nsproxy *nsproxy, struct ns_common *ns)
 	if (user_ns == current_user_ns())
 		return -EINVAL;
 
-	/* Threaded processes may not enter a different user namespace */
-	if (atomic_read(&current->mm->mm_users) > 1)
+	/* Shared signal handlers must live in the same user namespace */
+	if (atomic_read(&current->sighand->count) > 1)
 		return -EINVAL;
 
 	if (current->fs->users != 1)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1202256

On 08/05, Eric W. Biederman wrote:
>
> So I have to ask.

I hope you are asking someone else, not me ;) I never understood what
exactly we try to restrict and why.

> Is it possible to rework these checks such that we
> look at the sighand struct and signal sharing handling sharing instead
> of the count on the mm_struct?

Then why we can't simply check thread_group_empty() == T ? Why should we
worry about CLONE_SIGHAND at all?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web