Polkitd что это

polkit (Русский)

Состояние перевода: На этой странице представлен перевод статьи polkit. Дата последней синхронизации: 7 марта 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Устранение часто встречающихся неполадок#Разрешения сессии
sudo (Русский)
Пользователи и группы

polkit — это средство для управления правами приложений пользовательского уровня, позволяющее непривилегированным процессам решать административные задачи: единый интерфейс предоставления прав доступа к привилегированным операциям для непривилегированных приложений при помощи набора правил (политик) и шины D-Bus.

Polkit используется для управления общесистемными привилегиями. Данный фреймворк используется для предоставления непривилегированным процессам возможность выполнения действий, требующих прав администратора. В отличие от sudo, Polkit не наделяет процесс правами суперпользователя, а позволяет точно контролировать, какие действия разрешены, а какие нет.

Polkit может контролировать отдельные действия, такие как запуск GParted: при этом он проверяет имя пользователя и принадлежность оного к группе, например, является ли он членом группы wheel. Далее Polkit проверяет, какими правами наделены пользователи данной группы (есть ли вообще права на запуск?) и, если всё сходится (пользователь в нужной группе и у группы есть соответствующие права), требует ввести пароль для идентификации пользователя.

Установка

Агенты аутентификации

Агент аутентификации используется для подтверждения того, что пользователь текущего сеанса действительно является этим пользователем (путём ввода пароля текущего пользователя) или администратором (путём ввода пароля администратора). Пакет polkit содержит текстовый агент аутентификации, ‘pkttyagent’, который используется в качестве запасного варианта.

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

Cinnamon, Deepin, GNOME, GNOME Flashback, KDE, LXDE, LXQt, MATE, theShell и Xfce уже имеют в своём составе агенты аутентификации. В других графических окружениях вы можете выбрать одну из реализаций:

lxqt-policykit , который предоставляет /usr/bin/lxqt-policykit-agent
lxsession или lxsession-gtk3 , который предоставляет /usr/bin/lxpolkit
mate-polkit , который предоставляет /usr/lib/mate-polkit/polkit-mate-authentication-agent-1
polkit-efl-gitAUR , который предоставляет /usr/bin/polkit-efl-authentication-agent-1
polkit-gnome , который предоставляет /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1
polkit-kde-agent , который предоставляет /usr/lib/polkit-kde/polkit-kde-authentication-agent-1
ts-polkitagentAUR , который предоставляет /usr/lib/ts-polkitagent
xfce-polkitAUR или xfce-polkit-gitAUR , который предоставляет /usr/lib/xfce-polkit/xfce-polkit
polkit-dumb-agent-gitAUR , минималистичный агент, который предоставляет /usr/bin/polkit-dumb-agent

Настройка

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

Определения Polkit можно разделить на два вида:

Действия (actions) определены в XML-файлах .policy , расположенных в каталоге /usr/share/polkit-1/actions . Каждое действие имеет набор разрешений по умолчанию (например, для действия GParted нужно идентифицироваться как администратор). Значения по умолчанию можно переопределить, но редактирование этих файлов НЕ является правильным способом.
Правила авторизации (authorization rules) определены в JavaScript-файлах .rules . Их можно найти в двух местах: пакеты могут использовать /usr/share/polkit-1/rules.d (хотя мало кто это делает), а /etc/polkit-1/rules.d предназначен для локальных настроек.

Polkit работает поверх существующих систем разрешений в Linux — членство в группах, статус администратора — он не заменяет их. Файлы .rules определяют подмножество пользователей, ссылаются на одно (или несколько) действий, указанных в файлах actions, и определяют, с какими ограничениями эти действия могут быть выполнены этими пользователями. Например, файл правил может отменить стандартное требование для всех пользователей проходить аутентификацию в качестве администратора при использовании GParted, определив, что некоторым конкретным пользователям это не нужно. Другой пример: определённому пользователю вообще не разрешено использовать GParted.

Примечание: Это не исключает возможности запуска GParted другими средствами, не взаимодействующими с polkit, например, напрямую через командную строку. Поэтому polkit следует использовать для предоставления доступа к привилегированным сервисам для непривилегированных пользователей, а не для урезания прав (частично) привилегированных пользователей. В целях безопасности всё ещё следует использовать sudoers.

Действия

Совет: polkit-explorer-git AUR предоставляет простой графический интерфейс для просмотра действий Polkit.

Действия, доступные вам через polkit, зависят от установленных пакетов. Некоторые из них используются в нескольких средах рабочего стола (org.freedesktop.*), некоторые специфичны для конкретной среды рабочего стола (org.gnome.*), а некоторые специфичны для одной программы (org.gnome.gparted.policy). Команда pkaction выводит список всех действий, определённых в /usr/share/polkit-1/actions .

Чтобы получить представление о том, что может делать polkit, вот несколько часто используемых групп действий:

systemd-logind(org.freedesktop.login1.policy): выключение и перезагрузка системы, уход в ждущий и спящий режим, в том числе когда присутствуют другие пользователи.
udisks(org.freedesktop.udisks2.policy): монтирование файловых систем, разблокировка зашифрованных устройств.
NetworkManager(org.freedesktop.NetworkManager.policy): включение и выключение сети, wifi или мобильного широкополосного доступа.

Каждое действие определяется в теге в файле .policy. Например, файл org.gnome.gparted.policy содержит одно действие и выглядит примерно так:

    Authentication is required to run the GParted Partition Editor as root Требуется авторизация для запуска редактора разделов GParted с правами root gparted auth_admin auth_admin auth_admin  /usr/bin/gparted true

Атрибут id — это фактическая команда, посылаемая в D-Bus, тег message — это объяснение пользователю, когда требуется аутентификация, а icon_name — это вроде как очевидно.

Тег defaults — это место, в котором указаны разрешения или их отсутствие. Он содержит три параметра: allow_any, allow_inactive и allow_active. Неактивные сеансы — это, как правило, удалённые сеансы (SSH, VNC и т.д.), в то время как активные — это вход, выполненный непосредственно на машине через TTY или X. allow_any — это настройка, охватывающая оба сценария.

Для каждого из этих параметров доступны следующие опции:

no: Пользователю не разрешено выполнять действие. Поэтому нет необходимости в аутентификации.
yes: Пользователь может выполнять действие без какой-либо аутентификации.
auth_self: Аутентификация требуется, но пользователь не обязательно должен быть администратором.
auth_admin: Требуется аутентификация в качестве администратора.
auth_self_keep: То же самое, что и auth_self, но, подобно sudo, авторизация сохраняется на несколько минут.
auth_admin_keep: То же самое, что и auth_admin, но, подобно sudo, авторизация сохраняется на несколько минут.

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

В приведённом выше примере действия GParted пользователи должны аутентифицироваться как администраторы, чтобы использовать GParted, независимо от того, является ли сеанс активным или неактивным.

Правила авторизации

Правила авторизации, переопределяющие настройки по умолчанию, располагаются в указанных выше каталогах. Для всех целей, связанных с персональной конфигурацией одной системы, следует использовать только /etc/polkit-1/rules.d .

Метод addRule() используется для добавления функции, которая может вызываться всякий раз, когда выполняется проверка авторизации действия и субъекта. Функции вызываются в том порядке, в котором они были добавлены, пока одна из функций не вернёт значение. Таким образом, чтобы добавить правило авторизации, которое обрабатывается раньше других правил, в каталоге /etc/polkit-1/rules.d создайте файл с именем, которое при сортировке расположится перед другими файлами правил, например 00-early-checks.rules .

Структура файлов .rules достаточно понятна:

/* Разрешить пользователям из группы admin запускать GParted без аутентификации */ polkit.addRule(function(action, subject) < if (action.id == "org.gnome.gparted" && subject.isInGroup("admin")) < return polkit.Result.YES; >>);

Внутри функции проверяется ID запрошенного действия (org.gnome.gparted) и группы пользователя (admin), и при выполнении условий возвращается значение «yes».

Определение администраторов

Метод addAdminRule() используется для добавления функции, которая может быть вызвана, когда требуется аутентификация администратора. Функция указывает, какие идентификаторы могут быть использованы для аутентификации администратора при проверке авторизации, определяемой действием и субъектом. Добавленные функции вызываются в том порядке, в котором они были добавлены, пока одна из функций не вернёт значение.

Конфигурация по умолчанию находится в файле 50-default.rules , поэтому, если вы хотите изменить эти настройки, нужно скопировать его, к примеру, в файл 40-default.rules и редактировать уже его.

/etc/polkit-1/rules.d/50-default.rules

polkit.addAdminRule(function(action, subject) < return ["unix-group:wheel"]; >);

Примечание: Ваш пользователь должен быть указан как член группы в файле /etc/group . Простое указание этой группы в качестве основной группы пользователя не работает с polkit. Смотрите polkit issue 131.

Единственная часть, которую нужно отредактировать (после копирования), — это возвращаемый массив: в качестве кого должен аутентифицироваться пользователь, когда нужна аутентификация администратора? Если пользователь является членом группы, члены которой считаются администраторами, то ему нужно будет ввести только свой пароль. Если какой-то другой пользователь, например, root, является единственным администратором, то нужно будет ввести пароль root. Формат идентификации пользователя такой же, как и при назначении полномочий.

По умолчанию Arch делает всех членов группы wheel администраторами. Показанный ниже пример правила заставит polkit запрашивать пароль root вместо пароля обычного пользователя для аутентификации в качестве администратора.

/etc/polkit-1/rules.d/49-rootpw_global.rules

/* Всегда выполняем аутентификацию администраторов путём * запроса пароля root, аналогично опции rootpw в sudo */ polkit.addAdminRule(function(action, subject) < return ["unix-user:root"]; >);

Примеры

Отладка/журналирование

Следующее правило записывает подробную информацию о любом запрошенном доступе.

/etc/polkit-1/rules.d/00-log-access.rules

polkit.addRule(function(action, subject) Отключение ждущего и спящего режима

Следующее правило отключает ждущий и спящий режим для всех пользователей.

/etc/polkit-1/rules.d/10-disable-suspend.rules

polkit.addRule(function(action, subject) < if (action.id == "org.freedesktop.login1.suspend" || action.id == "org.freedesktop.login1.suspend-multiple-sessions" || action.id == "org.freedesktop.login1.hibernate" || action.id == "org.freedesktop.login1.hibernate-multiple-sessions") < return polkit.Result.NO; >>);

Отключение запроса пароля

Чтобы добиться чего-то похожего на опцию NOPASSWD из sudo и получить авторизацию только на основе идентификации пользователя/группы, вы можете создать пользовательские правила в /etc/polkit-1/rules.d/ . Это позволит вам отменить аутентификацию по паролю либо только для определённых действий, либо глобально. Пример набора правил можно посмотреть здесь: [1]

Глобально

Создайте следующий файл от имени root:

/etc/polkit-1/rules.d/49-nopasswd_global.rules

/* Разрешить членам группы wheel выполнять любые действия * без проверки пароля, аналогично "sudo NOPASSWD:" */ polkit.addRule(function(action, subject) < if (subject.isInGroup("wheel")) < return polkit.Result.YES; >>);

Замените wheel на любую нужную вам группу.

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

Существует также AUTH_ADMIN_KEEP , который позволяет сохранять авторизацию в течение 5 минут. Однако авторизация происходит для каждого процесса отдельно, следовательно, если один процесс запросит авторизацию в течение 5 минут, то другой процесс в любом случае запросит пароль снова.

Для определённых действий

Создайте следующий файл от имени root:

/etc/polkit-1/rules.d/49-nopasswd_limited.rules

/* Разрешить членам группы wheel выполнять определённые действия * без проверки пароля, аналогично "sudo NOPASSWD:" */ polkit.addRule(function(action, subject) < if ((action.id == "org.gnome.gparted" || action.id == "org.libvirt.unix.manage") && subject.isInGroup("wheel")) < return polkit.Result.YES; >>);

Выбранные здесь action.id являются лишь (рабочими) примерами для GParted и libvirt, но вы можете заменить их на любые другие по вашему вкусу, если они существуют (сделанные самостоятельно или поставляемые пакетом), также вы можете определить любую другую группу вместо wheel .

Оператор || используется для разграничения действий (логическое ИЛИ), а && означает логическое И и должен использоваться как последний оператор.

Udisks

Файловые менеджеры могут запрашивать пароль при попытке смонтировать устройство хранения или выдавать ошибку Not authorized или похожую. Подробности смотрите в статье udisks (Русский)#Настройка.

Разрешить управление отдельными юнитами systemd обычным пользователям

Можно предоставить определённым пользователям или группам возможность управлять определёнными юнитами. Например, вы можете захотеть, чтобы обычные пользователи могли запускать и останавливать wpa_supplicant:

/etc/polkit-1/rules.d/10-wifimanagement.rules

polkit.addRule(function(action, subject) < if (action.id == "org.freedesktop.systemd1.manage-units") < if (action.lookup("unit") == "wpa_supplicant.service") < var verb = action.lookup("verb"); if (verb == "start" || verb == "stop" || verb == "restart") < return polkit.Result.YES; >> > >);

Смотрите также

Документация Polkit
Authorization with PolKit [устаревшая ссылка 2023-06-17 ⓘ] (openSUSE Leap Security guide)

Polkit

Polkit (прежнее название: PolicyKit) — библиотека для UNIX-подобных операционных систем. API библиотеки используется для предоставления непривилегированным процессам возможности выполнения действий, требующих прав администратора. Использование Polkit противопоставляется использованию таких систем, как sudo, но не наделяет процесс пользователя правами администратора, а позволяет точно контролировать, что разрешено, а что запрещено.

1 Настройка
- 1.1 Действия polkit
- 1.2 Правила polkit
- 1.3 Журналирование действий polkit
- 1.4 Определение администраторов
- 2.1 Монтирование раздела и создание нового подключения без запроса пароля
- 2.2 Монтирование раздела и создание нового подключения с запросом пароля
Настройка

Архитектура Polkit оперирует двумя видами понятий — действия (actions) и правила (rules).

Действия polkit

Действия (actions) определены в XML-файлах .policy, расположенных в каталоге /usr/share/polkit-1/actions. Для каждого действия указан набор разрешений по умолчанию.

Действия, доступные через polkit, зависят от установленных пакетов. Некоторые из них используются в нескольких средах рабочего стола (org.freedesktop.*), некоторые специфичны для конкретной среды рабочего стола (org.gnome.*), а некоторые специфичны для одной программы (org.xfce.thunar). Вывести список всех действий, определённых в /usr/share/polkit-1/actions можно, выполнив команду pkaction .

Все политики находятся в /usr/share/polkit-1/actions/ в формате *.policy Каждая политика представляет собой xml-файл, в котором описываются запросы к polkit.

Каждое действие определяется в теге в файле .policy. Например, файл org.freedesktop.UDisks2.policy содержит несколько действий. Пример действия:
```
 id="org.freedesktop.udisks2.filesystem-mount-system"> Mount a filesystem on a system device  xml:lang="ru">Монтировать файловую систему на системном устройстве Authentication is required to mount the filesystem  xml:lang="ru">Для монтирования файловой системы требуется подтверждение подлинности пользователя Authentication is required to mount the filesystem  auth_admin auth_admin auth_admin_keep   
```
Элементы, которые используются внутри действия:
- атрибут id — команда, посылаемая в DBus;
- тег description — описание действия;
- тег message — сообщение, отображаемое пользователю при запросе учетных данных, когда требуется аутентификация;
- тег defaults — описывает параметры, установленные по умолчанию. Тег defaults содержит три параметра:
  - тег allow_any — запрос от любого пользователя.
  - тег allow_inactive — запрос от неактивного пользователя (неактивный сеанс — это, как правило, удалённые сеансы SSH, VNC и т.д.);
  - тег allow_active — запрос от активного пользователя (активные сеанс — это вход, выполненный непосредственно на машине через TTY или X).
  Каждый из элементов allow_any, allow_inactive и allow_active может содержать следующие значения:
  - yes — предоставить разрешения;
  - no — заблокировать разрешения;
  - auth_self — пользователь должен ввести свой пароль для аутентификации (обратите внимание, что этого разрешения недостаточно для большинства применений в многопользовательских системах, обычно рекомендуется разрешение auth_admin);
  - auth_self_keep — пользователь должен ввести свой пароль для аутентификации, авторизация сохраняется на несколько минут (обратите внимание, что этого разрешения недостаточно для большинства применений в многопользовательских системах, обычно рекомендуется разрешение auth_admin_keep);
  - auth_admin — пользователь должен ввести пароль администратора при каждом запросе;
  - auth_admin_keep — пользователь должен ввести пароль администратора, авторизация сохраняется на несколько минут.
  Правила polkit
  
  Правила авторизации (authorization rules) определены в JavaScript-файлах .rules. Polkit читает правилами из двух каталогов /usr/share/polkit-1/rules.d и /etc/polkit-1/rules.d , сортируя файлы в лексическом порядке на основе базового имени (если имена совпадают, файлы в /etc обрабатываются раньше файлов в /usr ). Например, для следующих четырех файлов порядок следующий:
  - /etc/polkit-1/rules.d/10-auth.rules
  - /usr/share/polkit-1/rules.d/10-auth.rules
  - /etc/polkit-1/rules.d/15-auth.rules
  - /usr/share/polkit-1/rules.d/20-auth.rules
  Менять стандартные правила polkit нельзя, так как при обновлении системы они могут быть перезаписаны. Необходимо создавать собственные правила в /etc/polkit-1/rules.d/ в формате *.rules. Правила выполняются в порядке названия по алфавиту, поэтому вначале пишутся цифры, чтобы указать приоритет правила.
  
  Структура файлов .rules:
```
polkit.addRule(function(action, subject) if (action.id == "policy" && vashe_uslovie return polkit.Result.YES; >; >); 
```
  - addRule() — используется для добавления функции, которая может вызываться всякий раз, когда выполняется проверка авторизации действия и субъекта;
  - policy — название политики, поведение которой нужно изменить;
  - vashe_uslovie — условие, если нужно изменить поведение политики для одного пользователя пишем subject.user == '%username%', если для группы, то subject.isInGroup('%groupname%');
  - polkit.Result.YES означает, что политика будет при выполнении условия правила предоставлять разрешение.
  Каждая функция должна возвращать одно из значений, соответствующие значениям, которые можно использовать в качестве значений по умолчанию:
  - NO;
  - YES;
  - AUTH_SELF;
  - AUTH_SELF_KEEP;
  - AUTH_ADMIN;
  - AUTH_ADMIN_KEEP;
  - NOT_HANDLED;
  Если правило возвращает polkit.Result.NOT_HANDLED, null, undefined или вообще не возвращает значение, пробуется следующая пользовательская функция.
  
  Журналирование действий polkit
  
  Используя правила polkit можно также делать записи в системный журнал. Метод log() записывает сообщение в системный журнал. Пример:
```
polkit.addRule(function(action, subject) if (action.id == "действие") polkit.log("action=" + action); polkit.log("subject=" + subject); > >); 
```
  В параметре action передается объект с информацией о совершенном процессе и связанные с этим действием параметры (например, если запрошенное действие монтирование съемного диска, то в параметре action будут переданы серийный номер диска, его id, файловая система и т.д).
  
  В параметре subject передается объект с информацией о пользователе, запустившем процесс. Этот объект имеет следующие атрибуты:
  - id — идентификатор процесса;
  - user — имя пользователя;
  - groups — список групп, в которые входит пользователь;
  - seat — местонахождение субъекта (пустое значение, если местонахождение не локальное);
  - session — сессия субъекта;
  - local — true, только если местонахождение имеет локальный характер;
  - active — true, только если сеанс активен.
  Определение администраторов
  
  Администратор — в Альт определён в правиле /etc/polkit-1/rules.d/50-default.rules :
```
polkit.addAdminRule(function(action, subject) return ["unix-group:wheel"]; >); 
```
  По умолчанию, запрашивается пароль пользователя, находящегося в группе wheel. Для того, чтобы запрашивался пароль root, необходимо добавить правило с числом меньше 50 в начале имени (т.к. конфигурация по умолчанию находится в файле 50-default.rules ) с таким содержанием:
```
polkit.polkit (function(action, subject) return ["unix-user:root"]; >); 
```
  Правило должно возвращать массив строк, где каждая строка имеет вид unix-group: , unix-netgroup: или unix-user: . Если правило возвращает null, undefined или вообще не возвращает значение, пробуется следующее правило.
  
  Примеры
  
  Пользователи часто жалуются на необходимость вводить пароль при монтировании разделов в файловом менеджере и создании нового подключения в NetworkManager, а также невозможность извлечь usb-диск или лоток оптического привода. За эти разрешения отвечают:
  
  org.freedesktop.udisks2.filesystem-mount-system — разрешение на монтирование файловых систем системных устройств
  
  org.freedesktop.udisks2.filesystem-mount-other-seat — разрешение на монтирование файловых систем пользователям, подключенным не к основному рабочему месту
  
  org.freedesktop.udisks2.eject-media-other-seat — разрешение на извлечение лотка оптического привода пользователям, подключенным не к основному рабочему месту
  
  org.freedesktop.udisks2.power-off-drive-other-seat — разрешение на извлечение usb-диска пользователям, подключенным не к основному рабочему месту
  
  org.freedesktop.NetworkManager.settings.modify.system — разрешение на создание и модификацию системных сетевых соединений
  
  Примечание: Устройства хранения информации, делятся на системные, которые не считаются извлекаемыми, и несистемные, к которым относятся USB подключаемые накопители, Flash медиа и оптические приводы. Для каждой из групп устройств, системных и несистемных (т.н. извлекаемых — removable), для одной операции часто нужно два polkit actions, по одному на группу устройств.
  
  Чтобы узнать является ли устройство системным, на которые распространяется действие org.freedesktop.udisks2.filesystem-mount-system, выполните сначала команду, которая выведет все подключенные накопители:
```
$ udisksctl status MODEL REVISION SERIAL DEVICE -------------------------------------------------------------------------- Micron MTFDKCD512TFK 0002V5LN 22293A5BBD07 nvme0n1
```
  Затем команду с именем вашего устройства. Например /dev/nvme0n1. Статус true для HintSystem, в выводе команды говорит, что это системное устройство:
```
$ udisksctl info -b /dev/nvme0n1|grep ' Device:\|HintSystem' Device: /dev/nvme0n1 HintSystem: true 
```
  Для несистемных устройств, на которые распространяется действие org.freedesktop.udisks2.filesystem-mount-other-seat, для HintSystem статус будет false
  
  Монтирование раздела и создание нового подключения без запроса пароля
  
  Сделаем так, чтобы если пользователь находится в системной группе xgrp, то для него запросы пароля не должны будут выполняться для этих действий. Для этого (все действия выполняются от root):
```
polkit.addRule(function(action, subject) if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" && subject.isInGroup("xgrp")) return polkit.Result.YES; >; if (action.id == "org.freedesktop.udisks2.filesystem-mount-other-seat" && subject.isInGroup("xgrp")) return polkit.Result.YES; >; if (action.id == "org.freedesktop.udisks2.eject-media-other-seat" && subject.isInGroup("xgrp")) return polkit.Result.YES; >; if (action.id == "org.freedesktop.udisks2.power-off-drive-other-seat" && subject.isInGroup("xgrp")) return polkit.Result.YES; >; >); 
```
```
polkit.addRule(function(action, subject) if (action.id == "org.freedesktop.NetworkManager.settings.modify.system" && subject.isInGroup("xgrp")) return polkit.Result.YES; >; >); 
```
```
# groupadd -r xgrp 
```
```
# gpasswd -a имя_пользователя xgrp 
```
  Монтирование раздела и создание нового подключения с запросом пароля
  
  Пример создания правила, разрешающего пользователю выполнять монтирование и извлечение устройств — с запросом пароля (при указании polkit.Result.AUTH_SELF — будет запрошен пароль текущего пользователя, polkit.Result.AUTH_ADMIN — администратора). При подключении съемного устройства записывать в системный журнал какое устройство было подключено и каким пользователем:
```
polkit.addRule(function(action, subject) polkit.log("action "+ action); polkit.log("subject "+ subject); if (action.id == "org.freedesktop.udisks2.filesystem-mount-system") return polkit.Result.AUTH_SELF; >; if (action.id == "org.freedesktop.udisks2.filesystem-mount") return polkit.Result.AUTH_SELF; >; if (action.id == "org.freedesktop.udisks2.filesystem-mount-other-seats") return polkit.Result.AUTH_SELF; >; >); 
```
  При монтировании USB-диска в системном журнале появятся записи:
```
Nov 22 12:57:12 host-15 polkitd[9879]: /etc/polkit-1/rules.d/99-udisk2_mount.rules:4: action [Action id='org.freedesktop.udisks2.filesystem-mount-system' id.version='FAT32' id.usage='filesystem' drive.serial='11101094E6BA1A00A4A5200A' id.label='ALT p8 xfce/x86_64' partition.flags='0x00000000' polkit.gettext_domain='udisks2' drive='UFD 2.0 Silicon-Power4G (/dev/sdb1)' partition.number='1' id.uuid='F076-C625' drive.vendor='UFD 2.0' device='/dev/sdb1' id.type='vfat' partition.type='0x0b' polkit.message='Authentication is required to mount $(drive)' drive.revision='PMAP' drive.model='Silicon-Power4G'] Nov 22 12:57:13 host-15 polkitd[9879]: /etc/polkit-1/rules.d/99-udisk2_mount.rules:5: subject [Subject pid=4673 user='test' groups= uucp,proc,cdrom,floppy,cdwriter,audio,radio,users,scanner,xgrp, vmusers,audit_group,audit1,test, seat='seat0' session='5' local=true active=true] 
```
  Таким образом, в системном журнале зарегистрировано, что usb-диск с серийным номером 11101094E6BA1A00A4A5200A был подключен пользователем test.
  
  Просмотреть факты подключения конкретного носителя, можно выполнив команду:
```
# journalctl |grep "drive.serial='11101094E6BA1A00A4A5200A'" 
```
  Ссылки
  1. Документация Polkit
  2. Polkit. Статья в Википедии
  3. Отличие системных устройств от извлекаемых (англ.яз.)
  PolicyKit - создание собственных правил (продолжение)
  
  Установленный в системе PolicyKit уже имеет некоторые встроенные инструменты командной строки. В дистрибутиве Fedora 21 их четыре.
  
  pkaction - служит для просмотра возможных действий, которые отслеживает PolicyKit. Эта утилита может использоваться вместо просмотра в текстовом редакторе файлов .policy. Это может оказаться удобнее, так как здесь работают такие вещи как конвейеры, grep и т.п. Запуск pkaction без параметров выводит список всех возможных действий. Параметр --action-id позволяет просмотреть конкретное действие. Добавление параметра --verbose дает возможность получить полную информацию о действии, в том числе и об установленных разрешениях для него.
```
# 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
```
  pkcheck - позволяет проверить, авторизовался ли процесс для выполнения действия.
  
  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 накопители монтируются автоматически и никакой пароль при этом вводить не требуется.
  
  Ниже представлен фрагмент файла /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy. Исходный файл довольно большой, поэтому для экономии места оставлены только те действия и соответствующие им правила по умолчанию, которые относятся к подключению накопителей. Также для экономии места элементы description и message на языках, отличных от английского и русского удалены.
```
<?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 > <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 > <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 > <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 > <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 > <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 > <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 требуется вводить пароль суперпользователя. Хотелось бы иметь возможность работать с виртуальными машинами так же, как с любыми другими пользовательскими приложениями - без ввода пароля.
  - файл org.libvirt.unix.policy описывает только два действия - мониторинг виртуальных машин и управление ими.
  - в файле org.libvirt.api.policy перечислены конкретные действия (остановка, перезапуск и т.д.), которые возможны, если предыдущая проверка пройдена.
  В данном случае интерес представляет действие "Manage local virtualized systems" в файле org.libvirt.unix.policy. Соответствующий фрагмент приведен ниже:
```
<action id > <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>
```
  Видно, что правила по умолчанию для выполнения данного действия требуют ввода пароля суперпользователя. Файл /etc/polkit-1/rules.d/32-libvirt-manage.rules с новым правилом будет выглядеть так:
```
//Правило, разрешающее управление виртуальными машинами членам группы red polkit.addRule(function(action, subject) < if (action.id = && subject.isInGroup("red")) < return polkit.Result.YES; > >);
```
  Примечание. Обратите внимание: в последнем примере вместо метода match() использован оператор эквивалентности ==. В данном случае это просто разные способы сделать одно и то же. Оба варианта работают.
  
  Не обязательно оформлять каждое правило в виде отдельного файла, как это было сделано выше. Вместо этого все собственные правила можно записать в единственном файле. Для этого их надо просто расположить друг за другом.
  
  Итог
  
  PolicyKit позволяет повысить удобство работы в операционной системе при сохранении достаточной степени ее защищенности от необдуманного или случайного вмешательства пользователя. Небольшую подстройку этой программной части вполне может выполнить практически любой. Самое главное здесь - соблюдать разумный баланс между теми самыми удобством и защищенностью.
  
  Linux-ru
  
  Polkit (прежнее название: PolicyKit) — библиотека для UNIX-подобных операционных систем. API библиотеки используется для предоставления непривилегированным процессам возможности выполнения действий, требующих прав администратора. Использование Polkit противопоставляется использованию таких систем, как sudo, но не наделяет процесс пользователя правами администратора, а позволяет точно контролировать, что разрешено, а что запрещено.
  - Ubuntu (с версии 8.04);
  - Fedora (с версии 8);
  - OpenSUSE (с версии 10.3);
  - Slackware (с версии 13.1).
```
[olej@dell ~]$ lsb_release -ircd Distributor ID: Fedora Description: Fedora release 23 (Twenty Three) Release: 23 Codename: TwentyThree 
```
```
[olej@dell ~]$ ps -A | grep polkit 979 ? 00:00:02 polkitd 1626 ? 00:00:01 polkit-gnome-au [olej@dell ~]$ service polkit status Redirecting to /bin/systemctl status polkit.service ● polkit.service - Authorization Manager Loaded: loaded (/usr/lib/systemd/system/polkit.service; static; vendor preset: enabled) Active: active (running) since Пн 2016-05-23 09:49:40 EEST; 3 days ago Docs: man:polkit(8) Main PID: 979 (polkitd) CGroup: /system.slice/polkit.service └─979 /usr/lib/polkit-1/polkitd --no-debug май 23 09:49:39 dell.localdomain systemd[1]: Starting Authorization Manager. май 23 09:49:40 dell.localdomain polkitd[979]: Started polkitd version 0.113 май 23 09:49:40 dell.localdomain polkitd[979]: Loading rules from directory /etc/polkit-1/rules.d май 23 09:49:40 dell.localdomain polkitd[979]: Loading rules from directory /usr/share/polkit-1/rules.d май 23 09:49:40 dell.localdomain polkitd[979]: Finished loading, compiling and executing 6 rules май 23 09:49:40 dell.localdomain systemd[1]: Started Authorization Manager. май 23 09:49:40 dell.localdomain polkitd[979]: Acquired the name org.freedesktop.PolicyKit1 on the system bus май 23 09:50:11 dell.localdomain polkitd[979]: Registered Authentication Agent for unix-session:1 (system bus name :1.43 [/usr/l. U.utf8) Hint: Some lines were ellipsized, use -l to show in full. 
```
```
Olej
```
  Olej Писатель Сообщения: 20006 Зарегистрирован: 24 сен 2011, 14:22 Откуда: Харьков Контактная информация:
  
  Re: polkit
  
  Непрочитанное сообщение Olej » 26 май 2016, 18:55
  
  Автор: А. Ракитин
  Дата публикации: март 2015 г.
  PolicyKit - создание собственных правил
  
  PolicyKit присутствует практически в любом современном дистрибутиве Linux. Он является хорошо отлаженной частью операционной системы и в то же время постоянно развивается вместе с ней. Как правило, работа PolicyKit почти незаметна для пользователя и редко требует вмешательства.
  
  PolicyKit служит одним из способов временной и частичной передачи административных полномочий обычному, непривилегированному пользователю. Для похожих целей существуют и другие программные средства, например, sudo. Но, в отличие от sudo, PolicyKit не предоставляет администраторских полномочий на весь процесс, а следует принципу минимальных разрешений. Другими словами, он дает права суперпользователя только для выполнения конкретного действия.
  
  Работает это следующим образом. Любой запрос на выполнение действия в системном контексте, поступивший от работающего пользовательского процесса, отслеживается с помощью PolicyKit. В соответствии с имеющимися правилами PolicyKit принимает решение о том, может ли быть выполнено это действие, и, если может, то - при выполнении каких условий. Это решение - запрет, разрешение или разрешение с условием - передается системной программе, которая затем действует соответствующим образом. Другими словами, хотя непривилегированный пользовательский процесс (Subject) и привилегированный системный процесс (Mechanism) общаются между собой напрямую, решение принимает третья сторона - PolicyKit.
  Похожие публикации:

Polkitd что это

polkit (Русский)

Установка

Агенты аутентификации

Настройка

Действия

Правила авторизации

Определение администраторов

Примеры

Отладка/журналирование

Отключение запроса пароля

Глобально

Для определённых действий

Udisks

Разрешить управление отдельными юнитами systemd обычным пользователям

Смотрите также

Polkit

Настройка

Действия polkit

Правила polkit

Журналирование действий polkit

Определение администраторов

Примеры

Монтирование раздела и создание нового подключения без запроса пароля

Монтирование раздела и создание нового подключения с запросом пароля

Ссылки

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

PolicyKit - это служба

Практика

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

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

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

Итог

Linux-ru

Re: polkit

Добавить комментарий Отменить ответ