Paul Moore

A quick note to confirm that after running with v0.4.2 for several hours the errors/warnings are indeed gone. Thanks again for your work on this.

As a pidfd is a reference to a task, I believe it should use the task's SID/label.

> There is an issue where if process A does pidfd_open() on process B, the pidfs entries will have process A's context instead of process B's, which is undesirable ......

I haven't had a chance to look at any code yet, I'm basing my comments purely on what has been written here and the [pidfs patchset cover letter](https://lore.kernel.org/all/[email protected]/), but you've...

> > I haven't had a chance to look at any code yet, I'm basing my comments purely on what has been written here and the [pidfs patchset cover letter](https://lore.kernel.org/all/[email protected]/),...

There is also still the original issue that we likely want to label pidfds based on their associated task, similar to what we do with process entries in procfs. While...

Hi @realsdx, thanks for the PR :) Unfortunately, it looks like the the CI test are failing because of a missing `seccomp_notif_addfd` struct declaration due to an older userspace/headers on...

FWIW, if I made the following changes on top of your PR I was able to get everything building: ```diff diff --git a/include/seccomp.h.in b/include/seccomp.h.in index 024aca537f64..568eabaad949 100644 --- a/include/seccomp.h.in +++...

Another quick comment, we'll likely want to add a new API level to `seccomp_api_get()` to indicate ADDFD support.

> What would be the best way to determine the addfd support at runtime? One issue with probing the IOCTL with notifyfd is that we need a valid notify fd...