Pavel Volkov <sailor@lists.xtsubasa.org> wrote: > On вторник, 17 сентября 2019 г. 14:33:39 MSK, Dmitry Alexandrov wrote: >>> Попробую изучить cgroup-ы, а это свойство есть и в v1, и в v2? >> Нет, это в первых. А в Дебиан уже по-умолчанию вторые завезли? > > Да, есть и первые, и вторые. А, ну тогда пока все в порядке. > Чтобы systemd использовал и монтировал вторые, надо добавить аргумент ядру: systemd.unified_cgroup_hierarchy=1 Ну да, «unified» — это как раз для первых и вторых разом. >> Тогда там само-то по себе все еще удобнее: возиться вручную с цифирью (а classid это число), если надо много разных классов создавать, уже не надо, можно буквами писать. >> >> Но есть и одно большое но: Систем-д. Он предъявляет монопольное право на распоряжение к-группами. Оно и на первые предъявлял, просто net_cls от него был свободен. А ко вторым, как вы знаете, все контроллеры слили в один, так что вот так по-простому: ...уже не сделаешь. Надо какой-то огород городить, чтобы при логине создавалось по своему ‘inet’у на каждого пользователя, причем вместе с отдельными правилами для Нетфильтра (хотя по делу они нафиг и не нужны). >> > > Я предполагаю делать так: $ systemd-run --user --scope --unit=inet.scope my_program Не так. Ибо так при запуске следующей программы будет: $ systemd-run --user --scope --unit=inet iceweasel Failed to start transient scope unit: Unit inet.scope already exists. «inet» и прочие именные к-группы для Систем-д должны быть slice’ами, а не scope’ами, то есть либо: $ systemd-run --user --slice=inet --scope iceweasel либо уж службой (ключи подобрать по вкусу): $ systemd-run --user --slice=inet --collect iceweasel $ systemd-run --user --slice=inet --pty --same-dir --wait --collect --service-type=exec bash В любом случае без побочек не обойтись. Так, для logind они больше не будут частью сессии, например. > При этом запускается my_program, и она засовывается в новую c-группу inet.scope, которая является подгруппой user@1000.service. И даже не нужны рут-права, и файлы от этой группы в /sys/fs/ тоже принадлежат пользователю. Ну как же не нужны, когда Нетфильтр управляется только им (и в этом весь его смысл)? > Далее я бы хотел добавить примерно такое правило в nftables: # nft add rule filter output meta cgroup <...> ip dscp set <...> > > Но не пойму, как определить числовой идентификатор группы, который тут требуется. systemd-cgls его не сообщает, а и в /sys/fs/cgroup тоже его нет. Вот-вот, в этом и затык, я же говорю: нету теперь его. Если с первыми к-группами без Систем-д достаточно было один раз при запуске системы общие правила для Нетфильтра подгрузить, то со вторыми под Систем-д придется для каждого пользователя отдельные заводить, причем не раньше чем этот пользователь залогинится. А как соберется разлогинится — желательно бы удалять, хотя баг, когда иначе при следующей правке правил Нетфильтр выплюнул бы невнятную ошибку [1], вроде бы исправили. [1] https://bugzilla.kernel.org/show_bug.cgi?id=201789 Pavel Volkov <sailor@lists.xtsubasa.org> wrote: > On вторник, 17 сентября 2019 г. 14:33:39 MSK, Dmitry Alexandrov wrote: >> # echo 1 > /sys/fs/cgroup/net_cls/inet/net_cls.classid >> # iptables -A OUTPUT -m cgroup --cgroup 1 -j ACCEPT >> # ip6tables -A OUTPUT -m cgroup --cgroup 1 -j ACCEPT > > А, стормозил, classid — это и есть ID группы в терминах нетфильтра. Придётся воспользоваться cgroups первой версии тогда. Не люблю их за изобилие точек монтирования. Да, как видите, лучше бы их за это как раз любили. :-) Ибо гибкость — большое благо. Причем они ведь достаточно были гибкими, чтобы если уж так кому хочется, то подмонтировать их все разом в такой же unified каталог, но нет: право выбора надо было выпилить.
Attachment:
signature.asc
Description: PGP signature