Oleg Nesterov writes:
> On 08/11, Eric W. Biederman wrote:
>>
>> Oleg Nesterov 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_
On 08/11, Eric W. Biederman wrote:
>
> Oleg Nesterov 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_TH
Oleg Nesterov 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
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
Oleg Nesterov 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
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
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
On Wed, Aug 5, 2015 at 11:13 AM, Eric W. Biederman
wrote:
> Kees Cook writes:
>
>> On Tue, Jul 28, 2015 at 1:55 PM, Ricky Zhou wrote:
>>> On Tue, Jul 28, 2015 at 11:17 AM, Eric W. Biederman
>>> wrote:
Kees Cook writes:
> From: Ricky Zhou
>
> Checking mm_users > 1 does no
Hmm.
On closer inspection this patch touches on a greater inconsistency then
the test to see if the task is the only task using the mm_struct.
We currently allow tasks created with clone to have a different user
namespace and to share a mm_struct, and I don't think that is wrong.
What we actual
Kees Cook writes:
> On Tue, Jul 28, 2015 at 1:55 PM, Ricky Zhou wrote:
>> On Tue, Jul 28, 2015 at 11:17 AM, Eric W. Biederman
>> wrote:
>>> Kees Cook writes:
>>>
From: Ricky Zhou
Checking mm_users > 1 does not mean a process is multithreaded. For
example, reading /proc/PID
Oleg Nesterov writes:
> On 07/29, Kirill A. Shutemov wrote:
>>
>> On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
>> > On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook wrote:
>> >
>> > > From: Ricky Zhou
>> > >
>> > > Checking mm_users > 1 does not mean a process is multithreaded. Fo
On 07/29, Kirill A. Shutemov wrote:
>
> On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
> > On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook wrote:
> >
> > > From: Ricky Zhou
> > >
> > > Checking mm_users > 1 does not mean a process is multithreaded. For
> > > example, reading /proc/PI
On Wed, Aug 5, 2015 at 4:53 AM, Kirill A. Shutemov wrote:
>> 'only' if it's multi-threaded, i.e. when some workload cares so much about
>> performance that it uses multiple threads?
>>
>> Can you see the contradiction there?
>
> I can. man 2 unshare:
>
> CLONE_NEWUSER requires that the cal
On Wed, Aug 05, 2015 at 01:38:54PM +0200, Ingo Molnar wrote:
>
> * Kirill A. Shutemov wrote:
>
> > On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
> > > On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook
> > > wrote:
> > >
> > > > From: Ricky Zhou
> > > >
> > > > Checking mm_users
* Kirill A. Shutemov wrote:
> On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
> > On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook wrote:
> >
> > > From: Ricky Zhou
> > >
> > > Checking mm_users > 1 does not mean a process is multithreaded. For
> > > example, reading /proc/PID/map
On Tue, Jul 28, 2015 at 02:35:04PM -0700, Andrew Morton wrote:
> On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook wrote:
>
> > From: Ricky Zhou
> >
> > Checking mm_users > 1 does not mean a process is multithreaded. For
> > example, reading /proc/PID/maps temporarily increments mm_users, allowing
>
On Tue, Jul 28, 2015 at 2:35 PM, Andrew Morton
wrote:
> On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook wrote:
>
>> From: Ricky Zhou
>>
>> Checking mm_users > 1 does not mean a process is multithreaded. For
>> example, reading /proc/PID/maps temporarily increments mm_users, allowing
>> other proces
On Tue, 28 Jul 2015 10:15:00 -0700 Kees Cook wrote:
> From: Ricky Zhou
>
> Checking mm_users > 1 does not mean a process is multithreaded. For
> example, reading /proc/PID/maps temporarily increments mm_users, allowing
> other processes to (accidentally) interfere with unshare() calls.
>
> Thi
On Tue, Jul 28, 2015 at 1:55 PM, Ricky Zhou wrote:
> On Tue, Jul 28, 2015 at 11:17 AM, Eric W. Biederman
> wrote:
>> Kees Cook writes:
>>
>>> From: Ricky Zhou
>>>
>>> Checking mm_users > 1 does not mean a process is multithreaded. For
>>> example, reading /proc/PID/maps temporarily increments m
(apologies for the dup, forgot to reply all)
userns_install in user_namespace.c (affects setns of a user
namespace): cde1975bc242f3e1072bde623ef378e547b73f91.
The check in check_unshare_flags is a little more complex. The
incorrect check was added in
cf2e340f4249b781b3d2beb41e891d08581f0e10 but I
Kees Cook writes:
> From: Ricky Zhou
>
> Checking mm_users > 1 does not mean a process is multithreaded. For
> example, reading /proc/PID/maps temporarily increments mm_users, allowing
> other processes to (accidentally) interfere with unshare() calls.
>
> This fixes observed failures of unshare
On 07/28/2015 01:15 PM, Kees Cook wrote:
> From: Ricky Zhou
>
> Checking mm_users > 1 does not mean a process is multithreaded. For
> example, reading /proc/PID/maps temporarily increments mm_users, allowing
> other processes to (accidentally) interfere with unshare() calls.
>
> This fixes obser
From: Ricky Zhou
Checking mm_users > 1 does not mean a process is multithreaded. For
example, reading /proc/PID/maps temporarily increments mm_users, allowing
other processes to (accidentally) interfere with unshare() calls.
This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly
retu
23 matches
Mail list logo
