Bug 29223 - Use polkit rules
: Use polkit rules
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/NetworkManager)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2013-07-24 13:06 by
Modified: 2017-02-24 14:37 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2013-07-24 13:06:10
С некоторых пор управление NM стало доступным исключительно пользователям,
входящим в группу _nmconnect. Правила polkit вида:

polkit.addRule(function(action, subject) {
    return polkit.Result.YES;
});

работать перестали. Можно ли сделать так, чтобы работали оба механизма? Второй
удобен тем, что работает еще и с udisks2, для которого аналогичной группы вроде
не предусмотрено.
------- Comment #1 From 2013-07-25 15:03:07 -------
Хак с _nmconnect добавлен для других целей, см.
http://lists.altlinux.org/pipermail/sisyphus/2013-July/361023.html.
Использовать ли эту группу в правилах polkit или нет - дело добровольное. Если
правила перестали работать, то причина скорее всего где-то в другом месте.
------- Comment #2 From 2013-07-25 15:31:48 -------
> Если правила перестали работать, то причина скорее всего где-то в другом месте.

Как бы это продиагностировать? Подозрение пало на NM из-за того, что со
сменными устройствами все осталось хорошо. Плюс добавился еще один не всегда
воспроизводящийся подземный стук - не поднимается ethernet-соединение в NM при:

# cat /etc/modprobe.d/disable-ipv6.conf 
options ipv6 disable=1
------- Comment #3 From 2013-07-25 17:17:10 -------
(В ответ на комментарий №2)
> > Если правила перестали работать, то причина скорее всего где-то в другом месте.
> 
> Как бы это продиагностировать? Подозрение пало на NM из-за того, что со
> сменными устройствами все осталось хорошо.

Смотря в чем это проявляется.

> Плюс добавился еще один не всегда
> воспроизводящийся подземный стук - не поднимается ethernet-соединение в NM при:
> 
> # cat /etc/modprobe.d/disable-ipv6.conf 
> options ipv6 disable=1

Надо смотреть лог при неудачной попытке. Но это лучше отдельной багой.
------- Comment #4 From 2013-07-26 08:17:57 -------
> Смотря в чем это проявляется.

Проявляется так - после обновления NM при попытке подключиться к новой
WiFi-сети появляется окошко:

Не удалось создать/включить соединение
(32) No session found for uid 500 (unknown)

Это сообщение сам NM сочиняет или показывает то, что вернул вызов метода dbus?
Если первое, то какое ему дело до наличия сессии, это ведь должны быть проблемы
polkit ...
------- Comment #5 From 2013-07-26 13:05:36 -------
(В ответ на комментарий №4)
> > Смотря в чем это проявляется.
> 
> Проявляется так - после обновления NM при попытке подключиться к новой
> WiFi-сети появляется окошко:
> 
> Не удалось создать/включить соединение
> (32) No session found for uid 500 (unknown)
> 
> Это сообщение сам NM сочиняет или показывает то, что вернул вызов метода dbus?
> Если первое, то какое ему дело до наличия сессии, это ведь должны быть проблемы
> polkit ...

Это не имеет никакого отношения к polkit. Это как раз то, для чего сделан хак с
_nmconnect. Я же писал в sisyphus@: считается, что у пользователей, входящих в
группу _nmconnect, всегда есть активная сессия (если нет systemd-logind). Иначе
информацию о сессиях пользователя NM пытается получить у systemd-logind. Он
должен знать об этом для того, чтобы определить, соединения какого пользователя
можно использовать.
------- Comment #6 From 2013-07-26 14:14:50 -------
В NetworkManager-0.9.8.0-alt5.git20130327 правило для polkit было необходимым -
без него я получал сообщение:

Не удалось создать/включить соединение
(32) Not authorized to control networking

Я понял письмо в sisyphus@ про группу _nmconnect так, что появился еще один
дополнительный способ использовать NM без systemd. Замечательно, но меня
устраивало старое поведение, а почему - об этом я уже сказал (общий с udisks2
способ настройки).

В NetworkManager-0.9.8.2-alt4.git20130711 требуется и правило для polkit, и
включение пользователя в группу _nmconnect. Почему? Раньше NM не интересовался,
есть ли у пользователя активная сессия, а теперь ему это потребовалось? Почему
бы просто не считать, что у текущего пользователя всегда есть активная сессия?

Я просто хочу понять логику. Вы посчитали приемлемым сделать хак с _nmconnect,
так почему следуя той же логике не расширить область действия хака вообще на
всех, а не только членов группы _nmconnect?
------- Comment #7 From 2013-07-26 16:09:57 -------
(В ответ на комментарий №6)
> В NetworkManager-0.9.8.0-alt5.git20130327 правило для polkit было необходимым -
> без него я получал сообщение:
> 
> Не удалось создать/включить соединение
> (32) Not authorized to control networking
> 
> Я понял письмо в sisyphus@ про группу _nmconnect так, что появился еще один
> дополнительный способ использовать NM без systemd. Замечательно, но меня
> устраивало старое поведение, а почему - об этом я уже сказал (общий с udisks2
> способ настройки).
> 
> В NetworkManager-0.9.8.2-alt4.git20130711 требуется и правило для polkit, и
> включение пользователя в группу _nmconnect. Почему? Раньше NM не интересовался,
> есть ли у пользователя активная сессия, а теперь ему это потребовалось? 

Не знаю как это работало раньше. Может что-то изменилось в NM, но вообще он это
проверял и тогда, когда использовал CK.

> Почему
> бы просто не считать, что у текущего пользователя всегда есть активная сессия?

Кто такой "текущий пользователь" с точки зрения демона NM, работающего от root?

> Я просто хочу понять логику. Вы посчитали приемлемым сделать хак с _nmconnect,
> так почему следуя той же логике не расширить область действия хака вообще на
> всех, а не только членов группы _nmconnect?

Потому что я не хочу сильно ломать логику работы NM. Я не уверен, что это не
приведет к непредвиденным эффектам. И в любом случае, это хак, пользоваться
которым надо сознательно.
------- Comment #8 From 2013-07-26 16:14:43 -------
> Кто такой "текущий пользователь" с точки зрения демона NM, работающего от root?

Ну вы ведь реализовали более сложную логику: определить, входит ли "текущий
пользователь" в группу _nmconnect

> ... я не хочу сильно ломать логику работы NM. Я не уверен, что это не
> приведет к непредвиденным эффектам. И в любом случае, это хак, пользоваться
> которым надо сознательно.

Понятно
------- Comment #9 From 2013-07-26 16:19:27 -------
(В ответ на комментарий №8)
> > Кто такой "текущий пользователь" с точки зрения демона NM, работающего от root?
> 
> Ну вы ведь реализовали более сложную логику: определить, входит ли "текущий
> пользователь" в группу _nmconnect

Это как раз самый простой способ, который я смог придумать. Другие варианты
есть, но их слишком сложно реализовать. Оно того не стоит.
------- Comment #10 From 2013-07-26 16:25:14 -------
(В ответ на комментарий №9)
> > Ну вы ведь реализовали более сложную логику: определить, входит ли "текущий
> > пользователь" в группу _nmconnect

А, в смысле тот uid в сообщении? Это просто nm-applet запрашивает у NM список
соединений, доступных пользователю. Это вообще все в библиотеке, которой
пользуется и сам NM.