On Wed, Sep 30, 2015 at 11:36 AM, Tycho Andersen <tycho.andersen@xxxxxxxxxxxxx> wrote: > On Wed, Sep 30, 2015 at 11:27:34AM -0700, Andy Lutomirski wrote: >> On Wed, Sep 30, 2015 at 11:13 AM, Tycho Andersen >> <tycho.andersen@xxxxxxxxxxxxx> wrote: >> > This patch introduces the concept of a seccomp fd, with a similar interface >> > and usage to ebpf fds. Initially, one is allowed to create, install, and >> > dump these fds. Any manipulation of seccomp fds requires users to be root >> > in their own user namespace, matching the checks done for >> > SECCOMP_SET_MODE_FILTER. >> > >> > Installing a filterfd has some gotchas, though. Andy mentioned previously >> > that we should restrict installation to filter fds whose parent is already >> > in the filter tree. This doesn't quite work in the case of created seccomp >> > fds, since once you install a filter fd, you can't install any other filter >> > fd since it has no parent and there is no way to "pre-chain" filters before >> > installing them. >> >> ISTM, if we like the seccomp fd approach, we should have them be >> created with a parent already set. IOW the default should be that >> their parent is the creator's seccomp fd and, if needed, creators >> could specify a different parent. > > Allowing people doing SECCOMP_FD_NEW to specify a parent fd would > work. Then we can disallow installing a seccomp fd if its parent is > not the current filter, and get rid of the whole mess with prev > locking and all that. > Yes, please. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
