Hello Yafang. On Sun, Sep 03, 2023 at 02:27:55PM +0000, Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > In our specific use case, we intend to use bpf_current_under_cgroup() to > audit whether the current task resides within specific containers. I wonder -- how does this work in practice? If it's systemd hybrid setup, you can get the information from the unified hierarchy which represents the container membership. If it's a setup without the unified hierarchy, you have to pick one hieararchy as a representation of the membership. Which one will it be? > Subsequently, we can use this information to create distinct ACLs within > our LSM BPF programs, enabling us to control specific operations performed > by these tasks. If one was serious about container-based ACLs, it'd be best to have a dedicated and maintained hierarchy for this (I mean a named v1 hiearchy). But your implementation omits this, so this hints to me that this scenario may already be better covered with querying the unified hierarchy. > Considering the widespread use of cgroup1 in container environments, > coupled with the considerable time it will take to transition to cgroup2, > implementing this change will significantly enhance the utility of BPF > in container scenarios. If a change like this is not accepted, will it make the transition period shorter? (As written above, the unified hierarchy seems a better fit for your use case.) Thanks, Michal
Attachment:
signature.asc
Description: PGP signature
