su не меняет все на другого пользователя (cgroups)

Если я запускаю эту команду:

su -l otheruser -c 'strace /usr/lib/systemd/systemd --user 2> /tmp/su.err'

Это не удается:

Не удалось создать корневую иерархию cgroup: разрешение отклонено

Не удалось выделить объект менеджера: разрешение отклонено

В выводе strace я вижу, что запуск systemd от имени пользователя здесь не удался:

mkdir("/sys/fs/cgroup/systemd/user/root/754/systemd-3893", 0755) = -1 
     EACCES (Permission denied)

Откуда берется /sys/fs/cgroup/systemd/user/root/?

Если я запускаю ту же команду через ssh на локальный хост, она работает:

ssh otheruser@localhost 'strace /usr/lib/systemd/systemd --user 2> /tmp/ssh.err'

Здесь используется правильный каталог:

mkdir("/sys/fs/cgroup/systemd/user/modwork_gew_dfj/825/systemd-4272", 0755) = 0

Почему через ssh работает, а через su нет?

Версия: su (GNU coreutils) 8.17

Обновлять

Здесь вы можете видеть, что контрольная группа не меняется в моей версии su:

host:~ # su -l otheruser
otheruser@host:~$ cat /proc/$PPID/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/root/5913 <################ root

Через ssh:

host:~ # ssh otheruser@host
otheruser@host:~$ cat /proc/$PPID/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/otheruser/5919 <################ otheruser

Обновление2

Моя версия su не меняет cgroup (см. ссылку в ответе пользователя "ax"). Есть ли способ изменить cgroup (до или после) вызова su?

Обновление3

В этой версии нет этой проблемы: su util-linux 2.25


person guettli    schedule 24.08.2016    source источник
comment
Просто спрашиваю... У вашей учетной записи root есть пароль, верно?   -  person Hackerman    schedule 26.08.2016
comment
какая у тебя версия системд?   -  person vsminkov    schedule 26.08.2016
comment
Это ошибка или фича, что su не меняет контрольную группу? Что говорят люди из gnu coreutils?   -  person guettli    schedule 29.08.2016
comment
Попробуйте su - полностью сбросить вашу среду и получить новую оболочку входа для root. (Вы также можете сделать это с конкретными пользователями, например, su - guettli)   -  person Adam Katz    schedule 29.08.2016
comment
@AdamKatz AFAIK su -l guettli делает то же самое, что и su - guettli.   -  person guettli    schedule 30.08.2016
comment
Да, это так. Мой плохой, я пропустил это.   -  person Adam Katz    schedule 30.08.2016


Ответы (2)


su наследует свои cgroup от исходного сеанса, не от пользователя, перешедшего на su. Поэтому, когда вы вызываете su -l otheruser -c systemd ... как root, systemd пытается использовать корневую контрольную группу (/sys/fs/cgroup/systemd/user/root/...) как otheruser и терпит неудачу.

С ssh otheruser@localhost ... и пользователь, и контрольная группа являются otheruser, и все работает как положено.

person ax.    schedule 26.08.2016
comment
Для меня это выглядит так, как будто su делает что-то не так. С su -l следует изменить контрольную группу. Есть ли способ изменить cgroup? Я хотел бы избежать ssh для локального хоста. - person guettli; 28.08.2016
comment
Пожалуйста, прочитайте ссылку в моем ответе (и systemd выдает ссылки). Именно потому, что su ведет себя непоследовательно, разработчики systemd добавили новую командную оболочку machinectl, которая должна делать именно то, что вы хотите. - person ax.; 28.08.2016
comment
Да, "machinectl может сработать. К сожалению, мне нужно поддерживать старую систему, в которой эта команда недоступна. Есть ли способ использовать cgexec (или другой инструмент) в сочетании с su, чтобы это заработало (без ssh)? - person guettli; 29.08.2016
comment
Я не знаю ни одного другого инструмента, который делает то, что вы хотите. Не является ведущим разработчиком systemd — отсюда и создание машинная оболочка. - person ax.; 31.08.2016
comment
Чтение справочная страница оболочки machinectl Я заметил следующее: Обратите внимание, что systemd-run(1) может использоваться вместо команды оболочки и позволяет больше детальная низкоуровневая конфигурация вызываемого юнита. Однако зачастую она имеет более высокий уровень привилегий, чем команда оболочки. Может ли это быть вариантом для вас? - person ax.; 31.08.2016
comment
черт, даже systemd-run не существует на этой старой платформе. Мне жаль. К сожалению, мне нужно поддерживать эту старую платформу... Спасибо за старания! - person guettli; 31.08.2016
comment
axe,guettli: есть ли еще прогресс в решении этой проблемы? Я поддерживаю эту старую систему sudo и выполняю команду под другим именем пользователя. Это работает в rhel 6.x с cgred, но теперь в rhel 7.2 systemd команда не может находиться в контрольной группе otheruser.slice без ssh otheruser@localhost - person porkchop; 19.11.2016

как указал guettli su больше не работает. в centos7.2 как root я пробовал, это работает для cgroup по uid: предположим, что у вас есть uid=1000, который является пользователем с высокой долей процессора, и uid=1001, который является пользователем с низкой долей процессора (я предполагаю, что по умолчанию каждый новый пользователь получает долю 1024, что будет иметь место для пользователя root (uid = 0))

в centos7.2 как root я пробовал это, похоже, работает для cgroup:

systemd-run --uid=1000 --slice=user-1000.slice do_uid_1000_work_commands
systemd-run --uid=1001 --slice=user-1001.slice do_uid_1001_work_commands

вышеприведенное создаст две специальные службы с соответствующей конфигурацией пользовательского фрагмента в /run/systemd/system/:

/run/systemd/system/*10345*

/run/systemd/system/run-10345.service

/run/systemd/system/run-10345.service.d:

50-Description.conf 50-ExecStart.conf 50-Slice.conf 50-User.conf

Вот остальные мои настройки: --> /etc/systemd/system/user-1000.slice.d/50-CPUShares.conf

[Slice]
CPUShares=4096

--> /etc/systemd/system/user-1001.slice.d/50-CPUShares.conf

[Slice]
CPUShares=1024

--> /usr/lib/systemd/system/user-1001.slice

[Unit]
Description=User and Session Slice for uid = 1001 (low cpu share user)
Documentation=man:systemd.special(7)
Before=slices.target

[Service]
Slice=user-1001
CPUShares=1024

--> /usr/lib/systemd/system/user-1000.slice

[Unit]
Description=User and Session Slice for uid = 1000 (high cpu share user)
Documentation=man:systemd.special(7)
Before=slices.target

[Service]
Slice=user-1000
CPUShares=4096
person porkchop    schedule 19.11.2016