On 15/06/2024 8.15 am, Andrei Borzenkov wrote:
On 14.06.2024 18:49, Mikhail Morfikov wrote:
On 14/06/2024 5.26 pm, Demi Marie Obenour wrote:
On Fri, Jun 14, 2024 at 10:06:34AM +0200, Mikhail Morfikov wrote:
On 13/06/2024 10.27 pm, Lennart Poettering wrote:
On Do, 13.06.24 21:38, Mikhail Morfikov (mmorfikov@xxxxxxxxx) wrote:
I'm trying to make the 4 things (systemd, cgrupsv2, cgrulesengd, and nftables)
work together, but I think I'm missing something.
Is "cgrulesengd" interfering with the cgroup tree?
Sorry, but that's simply not supported. cgroupv2 has a single-writer
rule, i.e. every part of the tree has only a single writer, a single
manager. And you must delegate a subtree to other managers if a
different manager shall also manage cgroups.
Hence, if you have something that just takes systemd managed processes
and moves them elsewhere, it's simply not supported. Sorry, you voided
your warranty.
Lennart
--
Lennart Poettering, Berlin
I don't need any warranty, I need a way to make this work.
I don't know anything about cgrulesengd, but from your post it seems
that it relies on scanning all processes and moving them to cgroups
based on information about them. This isn't compatible with systemd.
There are a few options that will work:
1. Change cgrulesengd to use systemd's D-Bus API to manage cgroups.
2. Run everything in a container that doesn't use systemd.
3. Stop using cgrulesengd, and instead use systemd units to define
cgroups. Then use other approaches (such as wrapper scripts) to
ensure that programs are launched in the correct systemd units.
There's no way I'm going to wrap every command in systemd's service/unit
file...
The question isn't really whether cgrulesengd + systemd is supported or
not, but why the terminal apps have issues. GUI apps work well and the
network packets of all the GUI apps can be matched in nftables based on
the cgroup path. So the setup works well except for the terminal apps.
It is still unclear why you are asking this on systemd list.
I'm asking because with cgroupsv1 everything was working just fine, i.e.
net_cls class + nftables + cgrulesengd + systemd. It was working well for
many years, but recently systemd started to bully my system with this 30s
boot delay when it detects that cgroupsv1 is used (I was using it only for
this net_cls). So where else should I ask the question why does
systemd+cgroupsv2+cgrulesengd work only partially? I had pretty decent
firewall config that was filtering INPUT/OUTPUT of all individual user
(and system too) apps, but now some part of it is broken, and I try to
figure out why and how to fix it.
From your description it sounds like a race condition between cgrulesengd and netfilter. GUI apps generally are "heavier" and take more time to startup which may explain it. The best place to ask would be cgrulesengd. If you have any evidence that systemd somehow interferes here, you did not present them.
The evidence could be the cgroup path. For instance, the curl processes
should be added via cgrulesengd to morfikownia/user/curl/ , and they are
added each single time I type curl in a terminal, or when curl is called
from some script. But when I checked why the network packets are dropped,
I found out that the following rule can catch them:
socket cgroupv2 level 1 "user.slice/"
When I dug deeper:
socket cgroupv2 level 3 "user.slice/user-1000.slice/user@1000.service/"
But there's no curl pids in /sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/cgroup.procs .
To be more specific, there's no pids at all in this cgroup.procs file. The curl pids are under
# cat /sys/fs/cgroup/morfikownia/user/curl/pids.current
1
# cat /sys/fs/cgroup/morfikownia/user/curl/cgroup.procs
44907
And this cgroup path (morfikownia/user/curl/) is permitted in nftables, and
yet packets sometimes are visible like they had user.slice/user-1000.slice/user@1000.service/
path set. Why? Would GUI apps vs. terminal apps explain this? Maybe there's some
problems with nftables (or nftables+systemd), I don't know, maybe I could ask at
nftables ML about this case (I probably will anyway).
Otherwise there is such project as
https://github.com/mk-fg/systemd-cgroup-nftables-policy-manager
which dynamically adds nftables rules to match systemd cgroups (well, in principle it can match anything). It could be combined with "systemd-run --scope" or similar to place commands in specific scopes that will be matched by netfilter.
I don't think the project is what I need.
