On Wed, Sep 30, 2020 at 10:34:51PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Tycho,
>
> Thanks for taking time to look at the page!
>
> On 9/30/20 5:03 PM, Tycho Andersen wrote:
> > On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
> >> 2. In order that the supervisor process can obtain notifications
> >> using the listening file descriptor, (a duplicate of) that
> >> file descriptor must be passed from the target process to the
> >> supervisor process. One way in which this could be done is by
> >> passing the file descriptor over a UNIX domain socket connec‐
> >> tion between the two processes (using the SCM_RIGHTS ancillary
> >> message type described in unix(7)). Another possibility is
> >> that the supervisor might inherit the file descriptor via
> >> fork(2).
> >
> > It is technically possible to inherit the fd via fork, but is it
> > really that useful? The child process wouldn't be able to actually do
> > the syscall in question, since it would have the same filter.
>
> D'oh! Yes, of course.
>
> I think I was reaching because in an earlier conversation
> you replied:
>
> [[
> > 3. The "target process" passes the "listening file descriptor"
> > to the "monitoring process" via the UNIX domain socket.
>
> or some other means, it doesn't have to be with SCM_RIGHTS.
> ]]
>
> So, what other means?
>
> Anyway, I removed the sentence mentioning fork().
Whatever means people want :). fork() could work (it's how some of the
tests for this feature work, but it's not particularly useful I don't
think), clone(CLONE_FILES) is similar, seccomp_putfd, or maybe even
cloning it via some pidfd interface that might be invented for
re-opening files.
> >> ┌─────────────────────────────────────────────────────┐
> >> │FIXME │
> >> ├─────────────────────────────────────────────────────┤
> >> │From my experiments, it appears that if a SEC‐ │
> >> │COMP_IOCTL_NOTIF_RECV is done after the target │
> >> │process terminates, then the ioctl() simply blocks │
> >> │(rather than returning an error to indicate that the │
> >> │target process no longer exists). │
> >
> > Yeah, I think Christian wanted to fix this at some point,
>
> Do you have a pointer that discussion? I could not find it with a
> quick search.
>
> > but it's a
> > bit sticky to do.
>
> Can you say a few words about the nature of the problem?
I remembered wrong, it's actually in the tree: 99cdb8b9a573 ("seccomp:
notify about unused filter"). So maybe there's a bug here?
> >> ┌─────────────────────────────────────────────────────┐
> >> │FIXME │
> >> ├─────────────────────────────────────────────────────┤
> >> │Interestingly, after the event had been received, │
> >> │the file descriptor indicates as writable (verified │
> >> │from the source code and by experiment). How is this │
> >> │useful? │
> >
> > You're saying it should just do EPOLLOUT and not EPOLLWRNORM? Seems
> > reasonable.
>
> No, I'm saying something more fundamental: why is the FD indicating as
> writable? Can you write something to it? If yes, what? If not, then
> why do these APIs want to say that the FD is writable?
You can't via read(2) or write(2), but conceptually NOTIFY_RECV and
NOTIFY_SEND are reading and writing events from the fd. I don't know
that much about the poll interface though -- is it possible to
indicate "here's a pseudo-read event"? It didn't look like it, so I
just (ab-)used POLLIN and POLLOUT, but probably that's wrong.
Tycho
