lkml.org 
[lkml]   [2019]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SECCOMP_RET_USER_NOTIF: listener improvements
On Wed, Apr 24, 2019 at 05:04:26PM +0200, Christian Brauner wrote:
> Hey everyone,
>
> So I was working on making use of the seccomp listener stuff and I
> stumbled upon a problem. Imagine a scenario where:
>
> 1. Task T1 installs Filter F1 and gets and listener fd for that filter FD1
> 2. T1 sends FD1 via SCM_RIGHTS to task T2
> T2 now holds a reference to the same underlying struct file as FD1 via FD2
> 3. T2 registers FD2 in an event loop and starts listening for events
> 4. T1 exits and wipes FD1
>
> Now, T2 still holds a reference to the filter via FD2 which references
> the same underlying file as FD1 which has the seccomp filter stashed in
> private_data.
> So T2 will never get notified that the filter is essentially unused and
> doesn't know when to exit, i.e. it has no way of telling when T1 and all
> of its children using the same filter are gone.
>
> I think we should have a way to do this

Since the only way we ever allow creating a struct file * that points
to a struct seccomp_filter *, if there is a notifier attached, the
number of tasks still being monitored by a particular filter should be
filter->usage - 1 (assuming there is a notifier attached). So we could
augment __put_seccomp_filter() to check for this and send out a
message with a SECCOMP_NOTIF_FLAG_DEAD flag or something.

> *or* alternatively have a way to attach a process to an existing
> filter.

I also think this wouldn't be too hard, since the struct file * has a
reference to the filter. So I guess the question is: which of these
makes more sense?

Tycho

\
 
 \ /
  Last update: 2019-04-24 17:21    [W:0.041 / U:1.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site