PolicyKit - создание собственных правил (продолжение)

Использование инструментов командной строки

Установленный в системе PolicyKit уже имеет некоторые встроенные инструменты командной строки. В дистрибутиве Fedora 21 их четыре.

# pkaction --action-id org.freedesktop.udisks2.filesystem-mount --verbose
org.freedesktop.udisks2.filesystem-mount:
  description:       Mount a filesystem
  message:           Authentication is required to mount the filesystem
  vendor:            The udisks Project
  vendor_url:        http://udisks.freedesktop.org/
  icon:              drive-removable-media
  implicit any:      auth_admin
  implicit inactive: auth_admin
  implicit active:   yes

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

pkttyagent - позволяет выполнить текстовую авторизацию таким приложениям, которые запускаются без пользовательского графического окружения, например, ssh.

Дополнительные пакеты могут включать некоторые другие утилиты и даже приложения с графическим интерфейсом, например, policytool. На практике все это не очень нужно обычному пользователю. Для создания своих правил достаточно любого текстового редактора.

И, конечно, нельзя не упомянуть команду man polkit.

PolicyKit - это служба

PolicyKit запускается и работает как служба операционной системы polkitd. Эта служба запускается от имени пользователя polkitd, который является обычным пользователем системы с ограниченными правами. Демон polkitd всегда стартует с правами суперпользователя и сразу после старта понижает права до обычного пользователя.

Каждый раз, когда приложение требует участия PolicyKit, демон polkitd запускается автоматически. Это обеспечивается средствами dbus-daemon или systemd. Поэтому пользователю никогда не приходится запускать polkitd вручную.

При каждом старте демона файлы .rules перечитываются заново. Поэтому изменения, внесенные в правила, начинают работать сразу, без перезапуска демона, сеанса пользователя или всей системы целиком.

Практика

Все примеры, приведенные ниже, проверены и работают. Их можно просто скопировать в файл правил. По крайней мере, это верно для Fedora 21.

При создании своих правил нужно иметь в виду, что, поскольку они являются программами, ошибки в синтаксисе недопустимы. Если ошибки все же имеются, то ничего фатального не произойдет, система не будет испорчена. Но правило работать не будет. Лучшее, что можно сделать в такой ситуации, это проверить, правильно ли указаны действие, группа пользователя и правило. Особенно это относится к названию действия. В разных дистрибутивах Linux, даже в разных версиях одного дистрибутива названия действий могут несколько отличаться от приведенных здесь. Также не лишним будет убедиться, что все нужные скобки и кавычки находятся на своих местах. В общем, как и всегда в программировании, здесь требуются внимательность и аккуратность.

Возможность подключение локальных дисков для обычного пользователя

В системе имеются два SATA жестких диска. На первом установлена операционная система, второй используется для хранения данных. Второй жесткий диск виден в файловом менеджере, но не смонтирован.

Проблема заключается в том, что каждый раз при попытке прочитать (подключить) второй SATA жесткий диск средствами файлового менеджера появляется окно агента PolicyKit с требованием ввести пароль суперпользователя. Между тем, любые USB накопители монтируются автоматически и никакой пароль при этом вводить не требуется.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>
  <vendor>The udisks Project</vendor>
  <vendor_url>http://udisks.freedesktop.org/</vendor_url>
  <icon_name>drive-removable-media</icon_name>

  <action id="org.freedesktop.udisks2.filesystem-mount">
    <description>Mount a filesystem</description>
    <description xml:lang="ru">Подключить файловую систему</description>
    <message>Authentication is required to mount the filesystem</message>
    <message xml:lang="ru">Для подключения файловой системы требуется подтверждение подлинности пользователя</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>
  
  <action id="org.freedesktop.udisks2.filesystem-mount-system">
    <description>Mount a filesystem on a system device</description>
    <description xml:lang="ru">Подключить файловую систему на системном устройстве</description>
    <message>Authentication is required to mount the filesystem</message>
    <message xml:lang="ru">Для подключения файловой системы требуется подтверждение подлинности пользователя</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>
  
  <action id="org.freedesktop.udisks2.filesystem-mount-other-seat">
    <description>Mount a filesystem from a device plugged into another seat</description>
    <description xml:lang="ru">Подключить файловую систему с устройства, подключенного в другое место</description>
    <message>Authentication is required to mount the filesystem</message>
    <message xml:lang="ru">Для подключения файловой системы требуется подтверждение подлинности пользователя</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>
  
  <action id="org.freedesktop.udisks2.filesystem-fstab">
    <description>Mount/unmount filesystems defined in the fstab file with the x-udisks-auth option</description>
    <description xml:lang="ru">Подключать/отключать заданные в файле fstab файловые системы с параметром x-udisks-auth</description>
    <message>Authentication is required to mount/unmount the filesystem</message>
    <message xml:lang="ru">Для подключения/отключения файловой системы требуется подтверждение подлинности пользователя</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>
  
  <action id="org.freedesktop.udisks2.filesystem-unmount-others">
    <description>Unmount a device mounted by another user</description>
    <description xml:lang="ru">Отключить устройство, подключённое другим пользователем</description>
    <message>Authentication is required to unmount a filesystem mounted by another user</message>
    <message xml:lang="ru">Для отключения устройства, подключённого другим пользователем, требуется подтверждение подлинности пользователя</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>
	...
</policyconfig>

Видно, что файл содержит описание нескольких различных действий, связанных с монтированием файловых систем. В данном случае требуется изменить правило по умолчанию, которое установлено для монтирования системных накопителей. Те накопители, которые подключены к интерфейсу SATA, наверняка относятся к системным.

Наиболее вероятным кандидатом для этого является правило org.freedesktop.udisks2.filesystem-mount-system. Видно, что правила по умолчанию требуют прав суперпользователя.

Для решения проблемы требуется дать права на монтирование файловой системы на системном устройстве той группе пользователей, к которой относится нужный нам пользователь. Пусть для определенности здесь и дальше это будет группа red.

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

//Правило, разрешающее монтирование файловой системы на системном устройстве членам группы red
polkit.addRule(function(action, subject) {
  if (action.id.match("org.freedesktop.udisks2.filesystem-mount-system") && subject.isInGroup("red")) {
    return polkit.Result.YES;
  }
});

Другой вариант - можно включить пользователя в какую-либо из уже существующих групп, например, disk и дать права на монтирование файловой системы на системном устройстве этой группе.

Файл с данным правилом следует поместить в каталог /etc/polkit-1/rules.d. Желательно, чтобы он был прочитан и обработан службой polkitd раньше, чем файлы правил, которые уже имеются в дистрибутиве. Для этого можно присвоить ему имя, например, 30-udisk2.rules.

Новое правило начинает работать сразу после создания файла.

Предоставление обычному пользователю прав на обновление системы и установку/удаление программ

В дистрибутиве Fedora имеется программа с графическим интерфейсом, позволяющая обновлять операционную систему и устанавливать или удалять программы - Yum Extender. Эти действия являются системными и требуют прав суперпользователя. Поэтому запуск Yum Extender сопровождается предложением ввести соответствующий пароль. На персональном компьютере это выглядит архаизмом и создает лишние трудности. Тем более, что установка программного обеспечения в современных дистрибутивах Linux производится как правило из проверенных источников, репозиториев. В отличие от некоторых других систем. Поэтому есть смысл разрешить данный класс операций непривилегированному пользователю.

Ниже представлен фрагмент файла /usr/share/polkit-1/actions/dk.yumex.backend.policy. Для упрощения в нем удалена декларация.

<policyconfig>
 <vendor>Yum Extender</vendor>
 <vendor_url>http://yumex.dk</vendor_url>
 <action id="dk.yumex.backend.pkexec.run">
    <description>Run Yum Extender backend</description>
    <message>Authentication is required for Yum Extender to handle packages on the system</message>
    <icon_name>yumex</icon_name>
    <defaults>
     <allow_any>no</allow_any>
     <allow_inactive>auth_admin</allow_inactive>
     <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/share/yumex/backend-launcher.py</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 </action>
</policyconfig>

Видно, что правила по умолчанию для запуска Yum Extender либо запрещают запуск программы, либо требуют прав суперпользователя. Для создания правила, позволяющего пользователю из группы red обновлять систему и устанавливать/удалять программы с помощью Yum Extender, снова можно воспользоваться тем же шаблоном. Результат будет таким:

//Правило, разрешающее обновлять систему и устанавливать/удалять программы членам группы red
polkit.addRule(function(action, subject) {
  if (action.id.match("dk.yumex.backend.pkexec.run") && subject.isInGroup("red")) {
    return polkit.Result.YES;
  }
});

Надо отметить, что для тех же самых действий, но выполняемых в командной строке с помощью yum, все равно потребуются полномочия суперпользователя. Созданное новое правило действительно только для Yum Extender.

Данный файл с правилом можно оформить как /etc/polkit-1/rules.d/31-yumex-backend.rules. Правило начинает работать немедленно.

Разрешение на управление виртуальными машинами с помощью virt-manager

Виртуальная машина на персональном компьютере - обычное явление. Но каждый раз при запуске графической программы управления virt-manager требуется вводить пароль суперпользователя. Хотелось бы иметь возможность работать с виртуальными машинами так же, как с любыми другими пользовательскими приложениями - без ввода пароля.

    <action id="org.libvirt.unix.manage">
      <description>Manage local virtualized systems</description>
      <message>System policy prevents management of local virtualized systems</message>
      <defaults>
        <allow_any>auth_admin_keep</allow_any>
        <allow_inactive>auth_admin_keep</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
      </defaults>
    </action>

//Правило, разрешающее управление виртуальными машинами членам группы red
polkit.addRule(function(action, subject) {
  if (action.id == "org.libvirt.unix.manage" && subject.isInGroup("red")) {
      return polkit.Result.YES;
  }
});

Примечание. Обратите внимание: в последнем примере вместо метода match() использован оператор эквивалентности ==. В данном случае это просто разные способы сделать одно и то же. Оба варианта работают.

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

Итог

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