Перевешиваю на polkit. Это он разрешает. systemd-run только спрашивает у него.

(In reply to comment #1)
> Перевешиваю на polkit. Это он разрешает. systemd-run только спрашивает у него.

А файл с описанием этой политики кто поставляет, systemd или polkit?

описание политики находится в
/usr/share/polkit-1/actions/org.freedesktop.systemd1.policy

$ rpmquery -f /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy systemd-239-alt3.x86_64

(В ответ на комментарий №3)
> описание политики находится в
> /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy
> 
> $ rpmquery -f /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy
> systemd-239-alt3.x86_64

нет, эта policy не имеет никакого отношения к systemd-run. Точнее там не упоминается ничего о systemd-run.

systemd-run подпадает под правило по-умолчанию /etc/polkit-1/rules.d/50-default.rules.

Если мы не будем ничего менять в правиле по-умолчанию, тогда да, надо перевесить баг обратно на systemd и придумывать политику специально для systemd-run.

Давайте лучше исправим сразу для всех пользователей polkit, а не только для systemd-run.

$ groups user uucp proc cdrom floppy cdwriter audio radio users vmusers video camera vboxusers xgrp scanner
$ systemd-run -t /bin/sh
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: System Administrator (root)
Password: 
==== AUTHENTICATION COMPLETE ==== Running as unit: run-u299.service
Press ^] three times within 1s to disconnect TTY.
sh-3.2# whoami
root

$ groups user wheel uucp proc cdrom floppy cdwriter audio radio users vmusers video camera vboxusers xgrp scanner
$ systemd-run -t /bin/sh
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: user Password: 
==== AUTHENTICATION COMPLETE ==== Running as unit: run-u307.service
Press ^] three times within 1s to disconnect TTY.
sh-3.2# whoami
root

вот здесь все прекрасно видно. если пользователь в группе wheel                         авторизуем с паролем пользователя. если пользователь не в группе wheel авторизуем с паролем рута

(In reply to comment #7)
> вот здесь все прекрасно видно. если пользователь в группе wheel                
>         авторизуем с паролем пользователя. если пользователь не в группе wheel
> авторизуем с паролем рута

Да, об этом и баг, что это неправильно.

$ grep -A8 \"org.freedesktop.systemd1.manage-units\" /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy
        <action id="org.freedesktop.systemd1.manage-units">
                <description gettext-domain="systemd">Manage system services or other units</description>
                <message gettext-domain="systemd">Authentication is required to manage system services or other units.</message>
                <defaults>
                        <allow_any>auth_admin</allow_any>
                        <allow_inactive>auth_admin</allow_inactive>
                        <allow_active>auth_admin_keep</allow_active>
                </defaults>
        </action>

(В ответ на комментарий №8)
> Да, об этом и баг, что это неправильно.

что конкретно? авторизовать с паролем пользователя?

(In reply to comment #10)
> (В ответ на комментарий №8)
> > Да, об этом и баг, что это неправильно.
> 
> что конкретно? авторизовать с паролем пользователя?

Да, аутентифицировать пользователя (по паролю) для авторизации рута.

ну тогда вам сюда
/etc/polkit-1/rules.d/50-default.rules
и таки да polkit считает пользователя в группе wheel рутом

вот нормальное описание
https://wiki.archlinux.org/index.php/Polkit#Administrator_identities

(In reply to comment #13)
> вот нормальное описание
> https://wiki.archlinux.org/index.php/Polkit#Administrator_identities

Не всё, что годится для Arch, годится для ALT.
Я могу себе представить какой-нибудь упрощённый дистрибутив вроде Simply,
где такая политика авторизации рута документирована и подходит, но в общем случае это уязвимость.

в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или паковать в отдельный пакет

(In reply to comment #7)

> вот здесь все прекрасно видно. если пользователь в группе wheel                
> авторизуем с паролем пользователя. если пользователь не в группе wheel
> авторизуем с паролем рута

Запрос на аналогичное поведение sudo (bug 18344) было решено не реализовывать. И тут оказывается, то в дистрибутивах с systemd есть второй путь для получения административных привилегий любым членом группы wheel.

To aris@ shrek@ shaba@
Пожалуйста, уделите внимание этому багу. ACL на пакет только на вас.
Может быть просто удалить 50-default.rules?

(Ответ для nbr на комментарий #17)
> To aris@ shrek@ shaba@
> Пожалуйста, уделите внимание этому багу. ACL на пакет только на вас.
> Может быть просто удалить 50-default.rules?

(Ответ для Valery Inozemtsev на комментарий #15)
> в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или
> паковать в отдельный пакет
Считаю некорректным предлагать мантейнеру пакета просто откреститься, а пользователям и релиз-менеджерам расхлёбывать.

polkit-123-alt1 -> sisyphus:

 Mon Dec 04 2023 Valery Inozemtsev <shrek@altlinux.ru> 123-alt1
 - 123
 - is not packed 50-default.rules (closes: #35763)

>  Mon Dec 04 2023 Valery Inozemtsev <shrek@altlinux.ru> 123-alt1
>  - is not packed 50-default.rules (closes: #35763)
﷐[U+1F4A9]﷑

А в p10 исправлять будут?

(Ответ для Sergey V Turchin на комментарий #22)
> А в p10 исправлять будут?

#335797

(Ответ для Valery Inozemtsev на комментарий #23)
> (Ответ для Sergey V Turchin на комментарий #22)
> > А в p10 исправлять будут?
> 
> #335797

Кто-нибудь одобрит?

(Ответ для Sergey V Turchin на комментарий #19)
> (Ответ для Valery Inozemtsev на комментарий #15)
> > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или
> > паковать в отдельный пакет
> Считаю некорректным предлагать мантейнеру пакета просто откреститься, а
> пользователям и релиз-менеджерам расхлёбывать.
Ну конкретно ради Simply, где и так sudo настраивается пользователю,
можно вынести в какой polkit-wheel-is-root.

Но вообще этих веб-макак пороть в детстве надо было, конечно,
а не набирать по объявлению системный софт писать :-/
Вчера собирал polkit-duktape 0.120 на сей счёт.

(Ответ для Антон Мидюков на комментарий #24)
> > > А в p10 исправлять будут?
> > #335797
> Кто-нибудь одобрит?
Да.

(Ответ для Michael Shigorin на комментарий #25)
> (Ответ для Sergey V Turchin на комментарий #19)
> > (Ответ для Valery Inozemtsev на комментарий #15)
> > > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или
> > > паковать в отдельный пакет
> > Считаю некорректным предлагать мантейнеру пакета просто откреститься, а
> > пользователям и релиз-менеджерам расхлёбывать.
> Ну конкретно ради Simply, где и так sudo настраивается пользователю,
> можно вынести в какой polkit-wheel-is-root.
> 
> Но вообще этих веб-макак пороть в детстве надо было, конечно,
> а не набирать по объявлению системный софт писать :-/
> Вчера собирал polkit-duktape 0.120 на сей счёт.

В каком смысле "ради Simply"?

Давайте мы дружно пересядем с локальных пользователей на доменных и посмотрим на проблему их глазами.

Предлагаю подумать откатить всё обратно. Либо предложить что-то разумное тысячам клиентов в домене, у которым после такого чудесного обновления в стабильном бранче отвалится доступ. Везде.

Никто не подумал, что нужно не группу выпиливать, а правило polkit'а, по умолчанию поменять?

(Ответ для Evgeny Sinelnikov на комментарий #27)
> (Ответ для Michael Shigorin на комментарий #25)
> > (Ответ для Sergey V Turchin на комментарий #19)
> > > (Ответ для Valery Inozemtsev на комментарий #15)
> > > > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или
> > > > паковать в отдельный пакет
> > > Считаю некорректным предлагать мантейнеру пакета просто откреститься, а
> > > пользователям и релиз-менеджерам расхлёбывать.
> > Ну конкретно ради Simply, где и так sudo настраивается пользователю,
> > можно вынести в какой polkit-wheel-is-root.
> > 
> > Но вообще этих веб-макак пороть в детстве надо было, конечно,
> > а не набирать по объявлению системный софт писать :-/
> > Вчера собирал polkit-duktape 0.120 на сей счёт.
> 
> В каком смысле "ради Simply"?
> 
> Давайте мы дружно пересядем с локальных пользователей на доменных и
> посмотрим на проблему их глазами.
> 
> Предлагаю подумать откатить всё обратно. Либо предложить что-то разумное
> тысячам клиентов в домене, у которым после такого чудесного обновления в
> стабильном бранче отвалится доступ. Везде.

Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить зависимость на него.

(Ответ для Evgeny Sinelnikov на комментарий #28)
> Никто не подумал, что нужно не группу выпиливать, а правило polkit'а, по
> умолчанию поменять?

О выпиливании какой группы речь? Как поменять?

(Ответ для Антон Мидюков на комментарий #29)
[...]
> 
> Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить
> зависимость на него.

Звучит очень странно. Нет, так не пойдёт.

Кто-нибудь может сказать какой action-id использует команда из-за которой весь сыр бор?:
$ systemd-run -t /bin/sh

(Ответ для Evgeny Sinelnikov на комментарий #28)
> нужно не группу выпиливать, а правило polkit'а, по умолчанию поменять
Так и сделали, вроде.

(Ответ для Evgeny Sinelnikov на комментарий #31)
> (Ответ для Антон Мидюков на комментарий #29)
> [...]
> > 
> > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить
> > зависимость на него.
> 
> Звучит очень странно. Нет, так не пойдёт.
> 

Почему? В p10 поведение не меняется. В p11 правило может быть включено в состав коробки дистрибутива. Никто ничего не заметит.

(Ответ для Антон Мидюков на комментарий #33)
> (Ответ для Evgeny Sinelnikov на комментарий #31)
> > (Ответ для Антон Мидюков на комментарий #29)
> > [...]
> > > 
> > > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить
> > > зависимость на него.
> > 
> > Звучит очень странно. Нет, так не пойдёт.
> > 
> 
> Почему? В p10 поведение не меняется. В p11 правило может быть включено в
> состав коробки дистрибутива. Никто ничего не заметит.

В каком смысле не поменяется. То есть правило, что wheel - это группа с админскими привилегиями убрали. А через эту группу доменные пользователи только и могут получать сейчас привилегии.

А доменные пользователи как будут их теперь получать? По паролю рута?



(Ответ для Sergey V Turchin на комментарий #32)
> (Ответ для Evgeny Sinelnikov на комментарий #28)
> > нужно не группу выпиливать, а правило polkit'а, по умолчанию поменять
> Так и сделали, вроде.

Так, да не так...


Вот дефолтные правила для action-id:

$ cat /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy |grep -i -e yes -e "action id"
  <action id="org.freedesktop.packagekit.cancel-foreign">
  <action id="org.freedesktop.packagekit.package-install">
  <action id="org.freedesktop.packagekit.package-install-untrusted">
  <action id="org.freedesktop.packagekit.package-reinstall">
  <action id="org.freedesktop.packagekit.package-downgrade">
  <action id="org.freedesktop.packagekit.system-trust-signing-key">
  <action id="org.freedesktop.packagekit.package-eula-accept">
      <allow_active>yes</allow_active>
  <action id="org.freedesktop.packagekit.package-remove">
  <action id="org.freedesktop.packagekit.system-update">
          - Changing this to anything other than 'yes' will break unattended
      <allow_active>yes</allow_active>
  <action id="org.freedesktop.packagekit.system-sources-configure">
  <action id="org.freedesktop.packagekit.system-sources-refresh">
      <allow_active>yes</allow_active>
  <action id="org.freedesktop.packagekit.system-network-proxy-configure">
      <allow_active>yes</allow_active>
  <action id="org.freedesktop.packagekit.device-rebind">
          - This should not be set to 'yes' as unprivileged users could then
      <allow_active>yes</allow_active>
  <action id="org.freedesktop.packagekit.upgrade-system">
  <action id="org.freedesktop.packagekit.repair-system">
  <action id="org.freedesktop.packagekit.trigger-offline-update">
      <allow_active>yes</allow_active>
  <action id="org.freedesktop.packagekit.trigger-offline-upgrade">
  <action id="org.freedesktop.packagekit.clear-offline-update">
      <allow_active>yes</allow_active>


Кто, вообще, решил, что удалённое правило является источником проблемы, обозначенной в заголовке этой задачи?

$ id
uid=758801104(sin) gid=758800513(domain users) группы=758800513(domain users),10(wheel),14(uucp),19(proc),22(cdrom),51(ftpadmin),71(floppy),80(cdwriter),81(audio),83(radio),100(users),101(localadmins),430(usershares),442(docker),448(vboxsf),451(hashman),461(vboxadd),463(fuse),467(video),477(vboxusers),480(camera),494(remote),498(xgrp),499(scanner),500(admin),501(sin_a),502(sin_b),758801110(software admins),758801125(server admins),758801126(docs admins),758801132(gpo admins),758801133(integration team),758801134(system team),758801136(public admins),758801178(workstation admins),758801183(security team)

$ sudo cat /etc/polkit-1/rules.d/50-default.rules
/* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */

// DO NOT EDIT THIS FILE, it will be overwritten on update
//
// Default rules for polkit
//
// See the polkit(8) man page for more information
// about configuring polkit.

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];
});


$ systemd-run -t /bin/sh
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: Evgeny Sinelnikov (sin)

(Ответ для Evgeny Sinelnikov на комментарий #34)
> (Ответ для Антон Мидюков на комментарий #33)
> > (Ответ для Evgeny Sinelnikov на комментарий #31)
> > > (Ответ для Антон Мидюков на комментарий #29)
> > > [...]
> > > > 
> > > > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить
> > > > зависимость на него.
> > > 
> > > Звучит очень странно. Нет, так не пойдёт.
> > > 
> > 
> > Почему? В p10 поведение не меняется. В p11 правило может быть включено в
> > состав коробки дистрибутива. Никто ничего не заметит.
> 
> В каком смысле не поменяется. То есть правило, что wheel - это группа с
> админскими привилегиями убрали. А через эту группу доменные пользователи
> только и могут получать сейчас привилегии.
> 

Я предложил в p10 собрать пакет с правилом, выставить зависимость у polkit в p10 на пакет с этим правилом. Итого в p10 это правило всегда будет, а в p11 его можно будет устанавливать или не устанавливать.

(Ответ для Антон Мидюков на комментарий #35)
[...]
> 
> Я предложил в p10 собрать пакет с правилом, выставить зависимость у polkit в
> p10 на пакет с этим правилом. Итого в p10 это правило всегда будет, а в p11
> его можно будет устанавливать или не устанавливать.

А что, в сущности, означает подход, при котором такое правило можно не устанавливать?

По-моему, очень просто получается. Получается, что без знания пароля рута, запрещаются любые административные действия.

Вариант без пароля я вообще не рассматриваю. Но в данном же случае речь совсем о другом. У меня 20 или 200 машин. С каким паролем рута их ставили уже никто не вспомнит. Логин осуществляется сетевым пользователем. Каким образом предлагается получать административные привилегии?

Водораздел проходит по вопросу получения рутового shell'а. Чем systemd-run -t /bin/sh доступный по группе wheel, отличается от sudo /bin/sh по группе wheel. Про это никто не договоривался. Про это, по умолчанию, нет.

Но дальше больше. Сейчас речь-то зашла о любых, вообще, административных действиях.

Почему? Потому что action_id соответствующий org.freedesktop.systemd1.manage-units трактуется слишком широко. Ну, можно было бы его отключить...

По идее админские привилегии доменный пользователь должен получать через пароль доменного пользователя при условии вхождения в какую-то группу.

Группа wheel лично меня устраивает, но у ldv были какие-то возражения по этому поводу (а может быть и не по этому).

Самое главное - для перехода на более высокие привилегии обязательно должен запрашиваться пользовательский пароль (или использоваться другая схема авторизации, настроенная для доменного пользователя а pam)

Локальные привилегии назначаются на основании назначенных локальных групп. Переписывать все приложения для поиска новых групп-привилегий - штука непонятная.

Делается такое назначение через модуль ролей.

- без модуля libnss-role:

$ grep ^group /etc/nsswitch.conf
group:      files [SUCCESS=merge] sss systemd

$ id sin
uid=87001104(sin) gid=87000513(domain users) группы=87000513(domain users),972(nfsuser),953(hashman),1001(sin_a),1002(sin_b),87000512(domain admins),87001115(dist admins),87000572(denied rodc password replication group)

- с модулем libnss-role:

$ grep ^group /etc/nsswitch.conf
group:      files [SUCCESS=merge] sss systemd role

$ id sin
uid=87001104(sin) gid=87000513(domain users) группы=87000513(domain users),972(nfsuser),953(hashman),1001(sin_a),1002(sin_b),87000512(domain admins),87001115(dist admins),87000572(denied rodc password replication group),100(users),36(vmusers),80(cdwriter),22(cdrom),81(audio),981(video),19(proc),83(radio),963(camera),71(floppy),998(xgrp),999(scanner),14(uucp),948(vboxusers),970(fuse),101(localadmins),10(wheel)

Правила назначения групп:

$ rolelst -V
# Settings read from /etc/role:
users:vmusers
domain users:users
domain admins:localadmins
# Resulting settings merged with /etc/role.d entries
users:vmusers,cdwriter,cdrom,audio,video,proc,radio,camera,floppy,xgrp,scanner,uucp,vboxusers,fuse
domain users:users
domain admins:localadmins
localadmins:wheel,vboxusers
powerusers:remote,vboxusers

(Ответ для Anton Farygin на комментарий #37)
[...]
> Самое главное - для перехода на более высокие привилегии обязательно должен
> запрашиваться пользовательский пароль (или использоваться другая схема
> авторизации, настроенная для доменного пользователя а pam)

Ну, то есть согласен с rider@. И даже более того. Других особых вариантов повышения привилегий для доменных пользователей, кроме как по группе, особо не вижу.

(Ответ для Evgeny Sinelnikov на комментарий #39)
> (Ответ для Anton Farygin на комментарий #37)
> [...]
> > Самое главное - для перехода на более высокие привилегии обязательно должен
> > запрашиваться пользовательский пароль (или использоваться другая схема
> > авторизации, настроенная для доменного пользователя а pam)
> 
> Ну, то есть согласен с rider@. И даже более того. Других особых вариантов
> повышения привилегий для доменных пользователей, кроме как по группе, особо
> не вижу.

Вторая неделя пошла, как дефолтное правило удалили в p10.
Непонятно, почему не возвращаем назад, если это проблема для доменных пользователей. Или не проблема?

(Ответ для Антон Мидюков на комментарий #40)
> > Других особых вариантов повышения привилегий для доменных пользователей,
> > кроме как по группе, особо не вижу.
> Вторая неделя пошла, как дефолтное правило удалили в p10.
> Непонятно, почему не возвращаем назад, если это проблема для доменных
> пользователей. Или не проблема?
Напрашивается отдельный пакет с внятным именем.

(Ответ для Michael Shigorin на комментарий #41)
> (Ответ для Антон Мидюков на комментарий #40)
> > > Других особых вариантов повышения привилегий для доменных пользователей,
> > > кроме как по группе, особо не вижу.
> > Вторая неделя пошла, как дефолтное правило удалили в p10.
> > Непонятно, почему не возвращаем назад, если это проблема для доменных
> > пользователей. Или не проблема?
> Напрашивается отдельный пакет с внятным именем.

Не знаю, как насчёт внятности, но такой пакет теперь есть. Это polkit-default-rules.
Багу закрываю.