Bug 2805

Вообще это происходит, когда есть ещё один открытый сеанс. То есть чтобы не валить что-то чужое просят пароль рута.

Но в каком случае это здесь вылезает надо ловить. Хотя я думаю как-нибудь вечером ты меня пустишь на эту машину и мы половим.

Это происходит даже если сеанс в консоли.

Но! 
Можно ли это убить совсем?

У нас десктоп, а не сервер — тот, кто у клавиатуры имеет все права на хибернацию.
Если нет — это надо делать.

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

(In reply to comment #3)
> Такое изменение непригодно для ентерпрайза - получается если админ сидит на
> твоей тачке по ссш/внц ( и у него открыта рутовая сессия ), ты сможешь
> просто тачку послать в гибернейт

И? Бородатый одмин забыл ssh сессию на топа лептопе и он теперь не хибернейтится?
WAT??? 

По крайней мере для мобильных устройст, т.е. лептопов, нет никакого оправдания запрету хибернейтится. Кстати, слипить то оно не мешает, хотя ssh админская сессия также отлично порвется.

Сессия в апстриме прописана явно - если открыта хоть одна root сессия или параллельная сессия гибернация и остальный действия не возможны. Менять это - сломать систему возможными проблемами с пробуждением вообще и полной поломко и это сделано не просто так.

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

(In reply to comment #6)
> Поэтому задача правильно описана - отловить левый рутовый процесс. А не
> городить ерунды со поломкой системной части, что нам потом аукнется при
> создании ентерпрайза.

Левый — это кроме X-ов и потомков?
Просьба набросать скрипты, которые должны в случае наблюдения подобного вычислить этот процесс (чтобы не тупо пялится в htop и т.п.)

Саша(ы), сможешь(ете)?

loginctl
он покажет нечто типо
   SESSION        UID USER             SEAT
        c1        482 gdm              seat0
        c3          0 root
и потом loginctl session-status c3
он покажет нечто типо
[root@grendizerlolpro background (master)]# loginctl session-status c3
c3 - root (0)
           Since: Tue, 15 Oct 2013 10:52:04 +0400; 1h 37min ago
          Leader: 28663 (su)
             TTY: pts/0
          Remote: user root
         Service: su; type tty; class user
           State: active
          CGroup: name=systemd:/user/root/c3
                  ├ 28663 su
                  ├ 28664 bash
                  ├ 29604 /usr/bin/mc -P /tmp/mc-root/mc.pwd.28664
                  ├ 29606 bash -rcfile .bashrc
                  └ 32455 loginctl session-status c3

Если что-то лишнее вылазит и uid этого < 500 , то надо найти и посмотреть в настройках dm. Возможно для gdm надо добавить в pam

# To allow reboot etc from greeter menu
session   required pam_systemd.so class=greeter

и посмотреть на его настройки, чтобы отсекало левые сессии через logind.

К примеру в lightdm отсекает вот ентих пользователей:

hidden-users=nobody nobody4 noaccess
hidden-shells=/bin/false /sbin/nologin

Также у нас уже всплывали левые root сессии через crond. Вот тут тоже надо как только не смогут выйти отлавливать.

Точно наблюдаю это даже на KDE версиях (+ на GNOMовых), где нет ни одного вручную запущенного root-а — ни в консолях, ни в терминале.

Но даже наличие рутового процесса в терминале, имхо, не должно быть причиной для препятствия хибернейту.

Ибо блокировка происходит неочевидно — экран гаснет (пользователь тут же может закрыть крышку и положить ноут в сумку), дальше экран снова включается (запрос рутового пароля), через пару секунд возникает экран блокировки (где нужно вводить пароль обычного пользователя).
В совокупности получается Ад и Израиль.

Я отловил crond, который что-то делала. Вообще по идее при выключении он должен что-то сказать процессу и попросить его выйти. И только если он не хочет завершаться, тогда просить пароль рута. А так, да Хелл и Сирия.

crond баг уже отлавливали, но быстро пофиксить увы и ах - надо ревизить всю систему скриптов.

По моему это anacron. Сегодня я прибил его процесс и пароль перестало спрашивать.

(In reply to comment #13)
> По моему это anacron. Сегодня я прибил его процесс и пароль перестало
> спрашивать.

Его можно отключить (не трогая cron, например)?
Отдельного сервиса anacron я не нашел.
Хочу попробовать на всех своих ноутах, ибо это наблюдаю частенько

На уровне непроверенной гипотезы.
Можно при вызове поверофф/ребут сервиса принудительно стопать крон/анакрон.
Но, как я по-моему уже говорил, это позволит прерывать запланированные админом таски ребутом/повероффом ).