Polkit linux что это

Обновлено: 06.07.2024

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

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

Polkit предоставляет API авторизации, предназначенный для использования привилегированными программами («МЕХАНИЗМЫ»), предлагающими услугу непривилегированным программам («СУБЪЕКТЫ») часто через какой-то механизм межпроцессного взаимодействия. В этом случае механизм обычно рассматривает объект как ненадежный. Для каждого запроса от субъекта механизм должен определить, разрешен ли запрос, или если он должен отказаться от обслуживания объекта. Используя API-интерфейсы polkit, механизм может разгрузить это решение доверенной стороне: полномочия polkit.

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

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

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

Содержание

Архитектура работы


Для удобства библиотека libpolkit-gobject-1 обертывает API-интерфейс polkit D-Bus и может использоваться из любой программы на C/C++, а также языки более высокого уровня, поддерживающие GObjectIntrospection, такие как JavaScript и Python. Механизм также может использовать API D-Bus или команду pkcheck для проверки разрешений. Библиотека libpolkit-agent-1 обеспечивает абстрагирование собственной системы аутентификации, например. pam, а также регистрация объектов и связь с услугой D-Bus polkit.

Дополнительную информацию о написании приложений polkit см. В документации разработчика.

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

Агент аутентификации используется, чтобы заставить пользователя сеанса доказать, что пользователь сеанса действительно является пользователем (путем аутентификации в качестве пользователя) или администратором (путем аутентификации в качестве администратора). Чтобы хорошо интегрироваться с остальной частью пользовательского сеанса (например, соответствовать внешнему виду), агенты аутентификации должны предоставляться сеансом пользователя, который пользователь использует.


Приложения, которые не запускаются в среде рабочего стола (например, если они запущены из входа ssh), возможно, не связаны с ними агентом проверки подлинности. Такие приложения могут использовать тип PolkitAgentTextListener или помощник pkttyagent, чтобы пользователь мог аутентифицироваться с использованием текстового интерфейса.

Конфигурация

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


Применение

Polkit используется в следующих дистрибутивах ОС Linux:

  • Ubuntu (с версии 8.04);
  • Fedora (с версии 8);
  • OpenSUSE (с версии 10.3);
  • Slackware (с версии 13.1).

Polkit позволяет непривилегированным пользователям выполнять некоторые действия, разрешённые администратором, (возможно, с запросом пароля пользователя или пароля администратора), например:

  • монтирование фс (например, образа iso, устройства с интерфейсом USB);
  • изменение параметров сетевого подключения (например, выбор другой точки доступа Wi-Fi).

Правила политики polkit

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

  • Запрос от любого пользователя. Тег <allow_any>
  • Запрос от неактивного пользователя. Тег <allow_inactive>
  • Запрос от активного пользователя <allow_active>

Внутри каждого тега прописывается возвращаемое значение. Используются следующие варианты значений:

  • yes - предоставить разрешения
  • no - заблокировать разрешения
  • auth_self - пользователь должен ввести свой пароль для аутентификации
  • auth_self_keep_session - пользователь должен ввести свой пароль для аутентификации один раз за сессию, разрешение предоставляется для всей сессии
  • auth_self_keep_always - пользователь должен ввести свой пароль для аутентификации один раз, разрешение предоставляется для текущей и будущих сессий
  • auth_admin - пользователь должен ввести пароль admin при каждом запросе
  • auth_admin_keep_session - пользователь должен ввести пароль admin, разрешение предоставляется для всей сессии
  • auth_admin_keep_always - пользователь должен ввести пароль admin, разрешение предоставляется для текущей и будущих сессий

По-умолчанию, запрашивается пароль пользователя, находящегося в группе wheel. Для того, чтобы запрашивался пароль root необходимо добавить правило с цифрами вначале имени больше 50 с таким содержанием:

Механизм

Сценарий использования Polkit:

  • Администратор создаёт файл в формате XML — список параметров (политики) для Polkit.
  • В системе от имени привилегированного пользователя запускаются фоновые процессы:
    • «D-Bus»;
    • какой-либо «daemon», выполняющий обслуживание запросов приложений пользователя.
    • subject — информация о авторе «просьбы» (uid, контекст SELinux и др.);
    • object — то, над чем будет выполняться действие (например, путь к блочному устройству, имя сетевого подключения);
    • action — действие (например, «монтирование», «подключение»).
    • запретить действие;
    • разрешить действие:
      • без запроса пароля;
      • с запросом пароля пользователя;
      • с запросом пароля пользователя root.

      В описанной схеме возможны изменения. Например, «daemon» при запуске может самостоятельно создавать файл конфигурации для Polkit, а при завершении — удалять его.

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

      Окно авторизации


      Окно авторизации.

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

      Немного о том, что это и как работает

      PolicyKit дополняет базовую модель разграничения прав доступа DAC (Discretionary Access Control), принятую в UNIX-подобных операционных системах. С небольшими упрощениями основную идею модели DAC можно изложить буквально в нескольких словах. Например, так: любой объект операционной системы является файлом и для каждого файла определены права на чтение, запись и выполнение отдельно для владельца, для членов группы и для всех остальных.

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

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

      Работает это следующим образом. Любой запрос на выполнение действия в системном контексте, поступивший от работающего пользовательского процесса, отслеживается с помощью PolicyKit. В соответствии с имеющимися правилами PolicyKit принимает решение о том, может ли быть выполнено это действие, и, если может, то - при выполнении каких условий. Это решение - запрет, разрешение или разрешение с условием - передается системной программе, которая затем действует соответствующим образом. Другими словами, хотя непривилегированный пользовательский процесс (Subject) и привилегированный системный процесс (Mechanism) общаются между собой напрямую, решение принимает третья сторона - PolicyKit.

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

      Логика работы PolicyKit


      Логика работы PolicyKit.

      Условием выполнения действия может быть, например, ввод оператором пароля. Для взаимодействия с оператором используется агент (Authentication agent), который при необходимости показывает оператору окно с соответствующим требованием. Агент предоставляется пользовательским окружением, например, агент PolicyKit для GNOME. Практически все современные пользовательские окружения, такие как GNOME, KDE, MATE, Xfce и другие, имеют в своем составе соответствующих агентов для взаимодействии с PolicyKit.

      PolicyKit включает в себя соответствующий программный интерфейс (API), предназначенный для того, чтобы приложения могли использовать его возможности. Именно в приложениях определяются те действия (Action), которые будет отслеживать PolicyKit. На практике могут встретится программы, которые не умеют взаимодействовать с PolicyKit. Но это скорее исключение.

      Для действий, которые определены в приложении, существуют соответствующие правила их выполнения (Authorization Rules). Набор таких правил для конкретного приложения называется политикой (Authorization policy).

      Примерно с 2007 года PolicyKit начал использоваться во всех наиболее популярных дистрибутивах Linux и их производных - в Debian, Ubuntu, Fedora, Red Hat, OpenSUSE, Gentoo, Slackware, Archlinux и многих других. Фактически он стал стандартом в своей области.

      Все изложенное ниже относится у дистрибутиву Fedora 21, но может с успехом использоваться для понимания принципов настройки PolicyKit в любых системах Linux. В данном случае использовалось пользовательское окружение MATE, но это также не принципиально.

      Разработчики дистрибутивов настраивают работу PolicyKit исходя из своих представлений о безопасности. Понятно, что сервер и рабочая станция будут иметь разные настройки. При адекватном выборе дистрибутива пользователь обычно не сталкивается с какими-либо неожиданными проблемами. Но иногда все же имеет смысл внести в работу PolicyKit некоторые изменения. Это один из тех немногих случаев, когда простыми средствами можно сделать собственный компьютер чуть более отзывчивым и дружелюбным.

      Явные и неявные разрешения

      Явные разрешения (Explicit privileges) относятся к конкретным пользователям или группам пользователей. При этом явные разрешения могут содержать ограничения. Например, ограничением может быть требование использовать только локальную консоль.

      Явные разрешения можно предоставлять или запрещать. Это похоже на всем известные списки доступа (ACL). Запрет имеет приоритет. Другими словами, если пользователю в одних политиках разрешено какое-либо действие, а в других оно запрещено, то выполнить это действие он не сможет.

      Неявные разрешения (Implicit privileges) определяются для пользовательской сессии в целом. Эти разрешения, в свою очередь, могут относится к активным или к неактивным сессиям. Активная сессия - это та, в которой пользователь работает в настоящий момент.

      Для принятия решения PolicyKit располагает информацией двух видов: описанием возможных действий и описанием правил для их выполнения.

      Файлы действий

      Список всех возможных действий содержится в файлах, которые находятся в каталоге /usr/share/polkit-1/actions. Эти файлы записаны в формате XML, что позволяет просматривать их в текстовом редакторе или даже в браузере.

      Имена файлов действий составлены из названия разработчика программного обеспечения (вендора), названия программы или группы действий и заканчиваются словом policy. Имя каждого файла вполне соответствует той группе действий, которые в нем перечислены. Средняя часть имени файла - название программы или группы действий - является в данном случае смысловой. Именно на нее надо обращать внимание, если требуется определить, в каком файле описано требуемое действие.

      Для примера посмотрим на содержание файла org.x.xf86-video-intel.backlight-helper.policy.

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

      Файлы и правила

      • /etc/polkit-1/rules.d - предполагается, что здесь располагаются некоторые файлы правил, подготовленные разработчиками дистрибутива и все файлы правил, подготовленные администратором системы. При персональной настройке правил располагать соответствующие файлы надо именно в этом каталоге.
      • /usr/share/polkit-1/rules.d - данный каталог содержит файлы правил, которые написаны разработчиками приложений и дистрибутива. Размешать файлы со своими правилами здесь настоятельно не рекомендуется из-за того, что при обновлении программ сделанные изменения скорее всего пропадут.

      В июне 2012 года David Zeuthen сообщил в своем блоге, что собирается переписать ту часть PolicyKit, которая работает с файлами правил. После проведения предварительных тестов он остановился на варианте с использованием языка программирования JavaScript. Такой выбор David обосновал тем, что ему хорошо знаком SpiderMonkey, интерпретатор JavaScript, а также тем, что он постоянно общается с людьми, которые имеют опыт его внедрения в GNOME Shell.

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

      Однако, решение было принято. Новая версия PolicyKit 0.106 работала уже с новыми файлами правил. Предполагалось, что именно эта версия будет включена в дистрибутив Fedora начиная с номера 18.

      Посмотреть версию установленного в системе PolicyKit можно, например,так:

      На самом деле указанная в выводе версия относится к утилите pkcheck, которая входит в комплект PolicyKit. Но она же соответствует всему комплекту в целом.

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

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

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

      Для тех, кому требуется быстрый результат, а не погружение в программирование на языке JavaScript, можно дать совсем краткие пояснения того, что делает приведенный в шаблоне программный код. В данном случае используется метод addRule (), который описывает некоторую функцию. Эта функция обеспечивает проверку возможности выполнения действия и выбирает для этого нужный тип авторизации в соответствии с правилом . Это правило действительно только для определенной группы пользователей .

      Действие - это значение id в элементе action в нужном файле действий .policy. Например, в приведенном выше файле это - org.x.xf86-video-intel.backlight-helper. При выборе нужного действия полезно внимательно прочитать его описание, приведенное в элементе description.

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

      Формулировка правил в целом совпадает с той, что используется в XML-файлах действий, которые были рассмотрены выше. Это - NO, YES, AUTH_SELF, AUTH_SELF_KEEP, AUTH_ADMIN, AUTH_ADMIN_KEEP. Они имеют тот же смысл, но в данном случае записываются в верхнем регистре.

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

      pkaction - служит для просмотра возможных действий, которые отслеживает PolicyKit. Эта утилита может использоваться вместо просмотра в текстовом редакторе файлов .policy. Это может оказаться удобнее, так как здесь работают такие вещи как конвейеры, grep и т.п. Запуск pkaction без параметров выводит список всех возможных действий. Параметр --action-id позволяет просмотреть конкретное действие. Добавление параметра --verbose дает возможность получить полную информацию о действии, в том числе и об установленных разрешениях для него. pkcheck - позволяет проверить, авторизовался ли процесс для выполнения действия.

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

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

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

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

      PolicyKit - это служба

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

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

      Практика

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

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

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

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

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

      Ниже представлен фрагмент файла /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy. Исходный файл довольно большой, поэтому для экономии места оставлены только те действия и соответствующие им правила по умолчанию, которые относятся к подключению накопителей. Также для экономии места элементы description и message на языках, отличных от английского и русского удалены.

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

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

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

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

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

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

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

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

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

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

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

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

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

      • файл org.libvirt.unix.policy описывает только два действия - мониторинг виртуальных машин и управление ими.
      • в файле org.libvirt.api.policy перечислены конкретные действия (остановка, перезапуск и т.д.), которые возможны, если предыдущая проверка пройдена.
      В данном случае интерес представляет действие "Manage local virtualized systems" в файле org.libvirt.unix.policy. Соответствующий фрагмент приведен ниже:

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

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

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

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

      Разрешить монтирование дисков в Linux, через Polkit

      Например раньше, когда приходилось разрешать монтировать диск, добавлялась специальная запись в sudoers файл, что то типа такого:

      Наверняка многие с этим сталкивались, на сегодня для этих целей можно использовать Polkit, для этого можно создать группу, назовем ее diskusers :

      После в нее необходимо добавить пользователя(ей):

      Далее создать разрешающее правило:

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

      Разрешить работать простым пользователям с Virtual Manager

      Многие сталкивались с тем, что при запуске KVM Virt Manager постоянно просит рутовый пароль, по аналогии можно создать группу, например virtusers , создать Polkit правило:

      Кейс о том, как разрешить запуск Pritunl сервиса юзеру без привилегий

      Сервис запускается после ввода OTP кода, для пользователя это окно выглядит так:

      allow pritunl with polkit

      Из скрина видно, что процесс polkit, пытается выполнить действие com.pritunl.client.profile_start , при детальном рассмотрении правила /usr/share/polkit-1/actions/com.pritunl.client.policy можно увидеть, что запуск разрешается только в случае использования auth_admin_keep , что означает проверку подлинности пользователя с правами администратора:

      .
      <action >
      <description>Start pritunl connection</description>
      .
      <allow_any>auth_admin_keep</allow_any>
      <allow_inactive>auth_admin_keep</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
      .
      </action>
      .

      Самым простым методом было-бы изменить auth_admin_keep на yes и все заработало без каких-либо проблем, но в таком случае этот процесс можно будет запускать всем, кому угодно, поэтому был выбран более правильный на мой взгляд путь:

      Читайте также: