On Wed, Sep 14, 2016 at 12:24 AM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > A Landlock program will be triggered according to its subtype/origin > bitfield. The LANDLOCK_FLAG_ORIGIN_SECCOMP value will trigger the > Landlock program when a seccomp filter will return RET_LANDLOCK. > Moreover, it is possible to return a 16-bit cookie which will be > readable by the Landlock programs in its context. Are you envisioning that the filters will return RET_LANDLOCK most of the time or rarely? If it's most of the time, then maybe this could be simplified a bit by unconditionally calling the landlock filter and letting the landlock filter access a struct seccomp_data if needed. > > Only seccomp filters loaded from the same thread and before a Landlock > program can trigger it through LANDLOCK_FLAG_ORIGIN_SECCOMP. Multiple > Landlock programs can be triggered by one or more seccomp filters. This > way, each RET_LANDLOCK (with specific cookie) will trigger all the > allowed Landlock programs once. This interface seems somewhat awkward. Should we not have a way to atomicaly install a whole pile of landlock filters and associated seccomp filter all at once? --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
