Hello Pablo. On Sun, Mar 23, 2025 at 10:20:10AM +0100, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > why classid != 0 is accepted for cgroup_mt_check_v0()? It is opposite, only classid == 0 is accepted (that should be same for all of v0..v2). (OTOH, there should be no change in validation with CONFIG_CGROUP_NET_CLASSID.) > cgroup_mt_check_v0 represents revision 0 of this match, and this match > only supports for clsid (groupsv1). > > History of revisions of cgroupsv2: > > - cgroup_mt_check_v0 added to match on clsid (initial version of this match) > - cgroup_mt_check_v1 is added to support cgroupsv2 matching > - cgroup_mt_check_v2 is added to make cgroupsv2 matching more flexible > I mean, if !IS_ENABLED(CONFIG_CGROUP_NET_CLASSID) then xt_cgroup > should fail for cgroup_mt_check_v0. I considered classid == 0 valid (regardless of CONFIG_*) as counterpart to implementation of sock_cgroup_classid() that collapses to 0 when !CONFIG_CGROUP_NET_CLASSID (thus at least rules with classid=0 remain acceptable). > But a more general question: why this check for classid == 0 in > cgroup_mt_check_v1 and cgroup_mt_check_v2? cgroup_mt_check_v1 is for cgroupv2 OR classid matching. Similar with cgroup_mt_check_v2. IOW, all three versions accept classid=0 with !CONFIG_CGROUP_NET_CLASSID equally because that is the value that sockets reported classid falls back to. But please correct me if I misunderstood the logic. Thanks, Michal
Attachment:
signature.asc
Description: PGP signature
