On Wed, Jan 15, 2014 at 1:04 PM, Oleg Nesterov wrote:
> On 01/14, Will Drewry wrote:
>>
>> On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov wrote:
>>
>> >> + get_seccomp_filter(caller);
>> >> + /*
>> >> + * Drop the task reference to the
On 01/15, Oleg Nesterov wrote:
>
> I think the
> locking is seriously broken in this series.
And imho seccomp_sync_threads() should fail "safely".
IOW, I think it should do while_each_thread() twice. The first
iteration should just check SECCOMP_MODE_FILTER/is_ancestor()
and fail if necessary. Th
On 01/14, Will Drewry wrote:
>
> On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov wrote:
>
> >> + get_seccomp_filter(caller);
> >> + /*
> >> + * Drop the task reference to the shared ancestor
> >> since
> >> + * curre
On Tue, Jan 14, 2014 at 3:09 PM, Andy Lutomirski wrote:
> On Tue, Jan 14, 2014 at 12:59 PM, Will Drewry wrote:
>> On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski wrote:
>>> On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry wrote:
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski
wrote:
On Tue, Jan 14, 2014 at 12:59 PM, Will Drewry wrote:
> On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski wrote:
>> On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry wrote:
>>> On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski
>>> wrote:
On 01/13/2014 12:30 PM, Will Drewry wrote:
> Applying
On Tue, Jan 14, 2014 at 1:21 PM, Oleg Nesterov wrote:
> On 01/13, Will Drewry wrote:
>>
>> +static pid_t seccomp_sync_threads(void)
>> +{
>> + struct task_struct *thread, *caller;
>> + pid_t failed = 0;
>> + thread = caller = current;
>> +
>> + read_lock(&tasklist_lock);
>> + i
On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski wrote:
> On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry wrote:
>> On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski wrote:
>>> On 01/13/2014 12:30 PM, Will Drewry wrote:
Applying restrictive seccomp filter programs to large or diverse
code
On Tue, Jan 14, 2014 at 2:13 PM, Oleg Nesterov wrote:
> On 01/14, Oleg Nesterov wrote:
>>
>> On 01/14, Oleg Nesterov wrote:
>> >
>> > > + get_seccomp_filter(caller);
>> > > + /*
>> > > + * Drop the task reference to the shared ancestor since
>> > >
On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry wrote:
> On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski wrote:
>> On 01/13/2014 12:30 PM, Will Drewry wrote:
>>> Applying restrictive seccomp filter programs to large or diverse
>>> codebases often requires handling threads which may be started earl
On 01/14, Oleg Nesterov wrote:
>
> On 01/14, Oleg Nesterov wrote:
> >
> > > + get_seccomp_filter(caller);
> > > + /*
> > > + * Drop the task reference to the shared ancestor since
> > > + * current's path will hold a reference. (Thi
On 01/14, Oleg Nesterov wrote:
>
> > + get_seccomp_filter(caller);
> > + /*
> > +* Drop the task reference to the shared ancestor since
> > +* current's path will hold a reference. (This also
> > +* all
On 01/13, Will Drewry wrote:
>
> +static pid_t seccomp_sync_threads(void)
> +{
> + struct task_struct *thread, *caller;
> + pid_t failed = 0;
> + thread = caller = current;
> +
> + read_lock(&tasklist_lock);
> + if (thread_group_empty(caller))
> + goto done;
> +
On 01/13, Will Drewry wrote:
>
> When prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_TSYNC, 0, 0) is called, it
> will attempt to synchronize all threads in current's threadgroup to its
> seccomp filter program.
TBH, I do not understand what this patch actually does ;) I'll try to
read it later. Still a co
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski wrote:
> On 01/13/2014 12:30 PM, Will Drewry wrote:
>> Applying restrictive seccomp filter programs to large or diverse
>> codebases often requires handling threads which may be started early in
>> the process lifetime (e.g., by code that is linked
On 01/13/2014 12:30 PM, Will Drewry wrote:
> Applying restrictive seccomp filter programs to large or diverse
> codebases often requires handling threads which may be started early in
> the process lifetime (e.g., by code that is linked in). While it is
> possible to apply permissive programs prio
15 matches
Mail list logo
