Bug 29223

Хак с _nmconnect добавлен для других целей, см. http://lists.altlinux.org/pipermail/sisyphus/2013-July/361023.html. Использовать ли эту группу в правилах polkit или нет - дело добровольное. Если правила перестали работать, то причина скорее всего где-то в другом месте.

> Если правила перестали работать, то причина скорее всего где-то в другом месте.

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

# cat /etc/modprobe.d/disable-ipv6.conf 
options ipv6 disable=1

(В ответ на комментарий №2)
> > Если правила перестали работать, то причина скорее всего где-то в другом месте.
> 
> Как бы это продиагностировать? Подозрение пало на NM из-за того, что со
> сменными устройствами все осталось хорошо.

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

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

Надо смотреть лог при неудачной попытке. Но это лучше отдельной багой.

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

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

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

Это сообщение сам NM сочиняет или показывает то, что вернул вызов метода dbus? Если первое, то какое ему дело до наличия сессии, это ведь должны быть проблемы polkit ...

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

Это не имеет никакого отношения к polkit. Это как раз то, для чего сделан хак с _nmconnect. Я же писал в sisyphus@: считается, что у пользователей, входящих в группу _nmconnect, всегда есть активная сессия (если нет systemd-logind). Иначе информацию о сессиях пользователя NM пытается получить у systemd-logind. Он должен знать об этом для того, чтобы определить, соединения какого пользователя можно использовать.

В 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?

(В ответ на комментарий №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. Я не уверен, что это не приведет к непредвиденным эффектам. И в любом случае, это хак, пользоваться которым надо сознательно.

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

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

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

Понятно

(В ответ на комментарий №8)
> > Кто такой "текущий пользователь" с точки зрения демона NM, работающего от root?
> 
> Ну вы ведь реализовали более сложную логику: определить, входит ли "текущий
> пользователь" в группу _nmconnect

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

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

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