Disable shutdown via ConsoleKit/PolicyKit

При свежей установке терминального сервера (Debian + LXDE + NX) случился пренеприятный косяк - приходящий в терминальный сеанс пользователь внезапно получал возможность остановить и перезагрузить сервер. При этом ни в группе powerdev, ни в sudoers, ни еще где-то записей об этом пользователе не было. Более того, из эмулятора терминала внутри nx-сессии также было невозможно сделать poweroff или reboot. 

Раз проблема проявляется только при взаимодействии с окружением рабочего стола, пришлось покопаться в PolicyKit. Однако, так как опыта тонкой настройки этого сервиса у меня нет, то я решил ограничиться следующим workaround-ом: в файле /etc/dbus-1/system.d/ConsoleKit.conf находим следующие строки:

    <allow send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.ConsoleKit.Manager"/>
    <allow send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.ConsoleKit.Seat"/>
    <allow send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.ConsoleKit.Session"/>
    <allow send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.DBus.Properties" />
    <allow send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="Restart"/>
    <allow send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="CanRestart"/>
    <allow send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="Stop"/>
    <allow send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="CanStop"/>

и меняем на

<deny send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.ConsoleKit.Manager"/>
    <deny send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.ConsoleKit.Seat"/>
    <deny send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.ConsoleKit.Session"/>
    <deny send_destination="org.freedesktop.ConsoleKit"
          send_interface="org.freedesktop.DBus.Properties" />
    <deny send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="Restart"/>
    <deny send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="CanRestart"/>
    <deny send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="Stop"/>
    <deny send_destination="org.freedesktop.ConsoleKit"
           send_interface="org.freedesktop.ConsoleKit.Manager"
           send_member="CanStop"/>

Таким образом все, кто входит в политику default (а это вообще все, ага ;) ), получают запрет на выполнение команд по выключению, перезагрузке, переходу в спящий режим и так далее. Конечно, главным недостатком этого "костыля" является то, что даже локальная X-сессия будет аналогично ограничена в возможности выключить компьютер. Но мы говорим о терминальном сервере, поэтому это некритично.

Восстановление работоспособности blueman

В один из дней после обычного для Sid-а aptitude dist-upgrade поломался bluetooth-applet. Точнее, blueman-applet, заменяющий дефолтный при установке сотфины blueman - более функционального и приятного менеджера голубозубых соединений. Сегодня выдалась свободная минутка, поэтому дошли руки поглядеть внимательнее, что сломалось.

Симптоматика следующая - после запуска рабочего стола (и апплета вместе с ним) blueman не может получить доступ к BT-адаптеру, показывая пустой список подключенных устройств, хотя сам адаптер подключен и системой корректно определяется:

delayer@inspire:~$ sudo hciconfig -a
hci0:    Type: BR/EDR  Bus: USB
    BD Address: 00:15:83:35:1D:6F  ACL MTU: 510:8  SCO MTU: 48:10
    UP RUNNING PSCAN ISCAN
    RX bytes:2056 acl:0 sco:0 events:80 errors:0
    TX bytes:4694 acl:0 sco:0 commands:78 errors:0
    Features: 0xff 0xfe 0xff 0xfe 0x98 0x3f 0x79 0x83
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy: RSWITCH HOLD SNIFF
    Link mode: SLAVE ACCEPT
    Name: 'ISSCEDRBTA'
    Class: 0x5a0104
    Service Classes: Networking, Capturing, Object Transfer, Telephony
    Device Class: Computer, Desktop workstation
    HCI Version: 2.1 (0x4)  Revision: 0x90e
    LMP Version: 2.1 (0x4)  Subversion: 0x316
    Manufacturer: Integrated System Solution Corp. (57)

Такой вот стоит дешевенький донгл без роду-племени (хотя, может и вру, на корпусе логотип Acorp-а есть). Запуск апплета (или любой другой софтинки вида blueman-*) консольно проходил успешно, но с тем же результататом - нужные пункты меню выбирались, но не нажимались, а в логах узрелось нечто вида: "except dbus.DBusServiceUnknownError:". Раскопки этих ваших интернетов привели к workaround-у: а) добавить пользователя в группы dbus и uucp б) запускать апплет через ck-launch-session (некая приблуда ConsoleKit-ная). То бишь проблема, оказывается, с правами доступа. Дальнейший гуглинг вывел на файл /etc/dbus-1/system.d/bluetooth.conf, 

 <!-- This configuration file specifies the required security policies
     for Bluetooth core daemon to work. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- ../system.conf have denied everything, so we just punch some holes -->

  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>

    <!-- allow root to send to agents -->
    <allow send_interface="org.bluez.Agent"/>
  </policy>

  <!-- allow users at the console, see consolekit or libpam-foreground -->
  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>

  <!-- allow users of bluetooth group to communicate with hcid -->
  <policy group="bluetooth">
    <allow send_destination="org.bluez"/>
  </policy>

  <policy context="default">
    <deny send_destination="org.bluez"/>
  </policy>

</busconfig>

где описываются политики для демона bluetoothd. Чтение его внутренностей показало, что доступ к демону и иже с ним имеют только а) root (отсюда работоспособность через sudo и ck-launch-session) и б) группа bluetooth.

Таким образом sudo adduser delayer bluetooth с последующим релогином проблему решает.

З.Ы.: XML-файлик удалось беспроблемно вставить в текст после прогона через эту форму.