'\" t .\" Title: polkit .\" Author: [see the "AUTHOR" section] .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: February 2022 .\" Manual: polkit .\" Source: Debian .\" Language: English .\" .TH "POLKIT" "8" "February 2022" "Debian" "polkit" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" polkit \- Authorization Manager .SH "OVERVIEW" .PP polkit provides an authorization API intended to be used by privileged programs (\(lqMECHANISMS\(rq) offering service to unprivileged programs (\(lqSUBJECTS\(rq) often through some form of inter\-process communication mechanism\&. In this scenario, the mechanism typically treats the subject as untrusted\&. For every request from a subject, the mechanism needs to determine if the request is authorized or if it should refuse to service the subject\&. Using the polkit APIs, a mechanism can offload this decision to a trusted party: The polkit authority\&. .PP The Debian\-specific version of polkit documented in this manual page uses authorization rules compatible with polkit 0\&.105 and earlier\&. .PP The polkit authority is implemented as an system daemon, \fBpolkitd\fR(8), which itself has little privilege as it is running as the \fIpolkitd\fR system user\&. Mechanisms, subjects and authentication agents communicate with the authority using the system message bus\&. .PP In addition to acting as an authority, polkit allows users to obtain temporary authorization through authenticating either an administrative user or the owner of the session the client belongs to\&. This is useful for scenarios where a mechanism needs to verify that the operator of the system really is the user or really is an administrative user\&. .SH "SYSTEM ARCHITECTURE" .PP The system architecture of polkit is comprised of the \fIAuthority\fR (implemented as a service on the system message bus) and an \fIAuthentication Agent\fR per user session (provided and started by the user\*(Aqs graphical environment)\&. \fIActions\fR are defined by applications\&. Vendors, sites and system administrators can control authorization policy through \fIAuthorization Rules\fR\&. .sp .RS 4 [IMAGE]\&\s-2\u[1]\d\s+2 .sp .if n \{\ .RS 4 .\} .nf +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | Authentication | | Agent | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | libpolkit\-agent\-1 | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ ^ +\-\-\-\-\-\-\-\-\-+ | | Subject | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-+ | ^ | | User Session | | =======================|========================|============= System Context | | | | | +\-\-\-+ V | /\-\-\-\-\-\-\-\-\-\-\-\-\e | | System Bus | | \e\-\-\-\-\-\-\-\-\-\-\-\-/ | ^ ^ V | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | Mechanism | | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ V +\-\-\-\-> | libpolkit\-gobject\-1 | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | polkitd(8) | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | org\&.freedesktop\&. | | PolicyKit1 |<\-\-\-\-\-\-\-\-\-+ +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | ^ | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | /usr/share/polkit\-1/actions/*\&.policy | | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | /etc/polkit\-1/localauthority/*/*\&.pkla | | /var/lib/polkit\-1/localauthority/*/*\&.pkla | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ .fi .if n \{\ .RE .\} .RE .PP For convenience, the libpolkit\-gobject\-1 library wraps the polkit D\-Bus API and is usable from any C/C++ program as well as higher\-level languages supporting \m[blue]\fBGObjectIntrospection\fR\m[]\&\s-2\u[2]\d\s+2 such as JavaScript and Python\&. A mechanism can also use the D\-Bus API or the \fBpkcheck\fR(1) command to check authorizations\&. The libpolkit\-agent\-1 library provides an abstraction of the native authentication system, e\&.g\&. \fBpam\fR(8) and also facilities for registration and communication with the polkit D\-Bus service\&. .PP See the \m[blue]\fBdeveloper documentation\fR\m[]\&\s-2\u[3]\d\s+2 for more information about writing polkit applications\&. .SH "AUTHENTICATION AGENTS" .PP An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator)\&. In order to integrate well with the rest of the user session (e\&.g\&. match the look and feel), authentication agents are meant to be provided by the user session that the user uses\&. For example, an authentication agent may look like this: .sp .RS 4 [IMAGE]\&\s-2\u[4]\d\s+2 .sp .if n \{\ .RS 4 .\} .nf +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | [Icon] Authentication required | | | | Authentication is required to format INTEL | | SSDSA2MH080G1GC (/dev/sda) | | | | Administrator | | | | Password: [__________________________________] | | | | [Cancel] [Authenticate] | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ .fi .if n \{\ .RE .\} .RE .PP If the system is configured without a \fIroot\fR account, it may prompt for a specific user designated as the administrative user: .sp .RS 4 [IMAGE]\&\s-2\u[5]\d\s+2 .sp .if n \{\ .RS 4 .\} .nf +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ | | | [Icon] Authentication required | | | | Authentication is required to format INTEL | | SSDSA2MH080G1GC (/dev/sda) | | | | [Icon] David Zeuthen | | | | Password: [__________________________________] | | | | [Cancel] [Authenticate] | +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+ .fi .if n \{\ .RE .\} .RE .PP Applications that do not run under a desktop environment (for example, if launched from an \fBssh\fR(1) login) may not have an authentication agent associated with them\&. Such applications may use the PolkitAgentTextListener type or the \fBpkttyagent\fR(1) helper so the user can authenticate using a textual interface\&. .SH "DECLARING ACTIONS" .PP A mechanism needs to declare a set of \fIactions\fR in order to use polkit\&. Actions correspond to operations that clients can request the mechanism to carry out and are defined in XML files that the mechanism installs into the /usr/share/polkit\-1/actions directory\&. .PP polkit actions are namespaced and can only contain the characters "[A\-Z][a\-z][0\-9]\&.\-", e\&.g\&. ASCII, digits, period and hyphen\&. Each XML file can contain more than one action but all actions need to be in the same namespace and the file needs to be named after the namespace and have the extension \&.policy\&. .PP The XML file must have the following doctype declaration .sp .if n \{\ .RS 4 .\} .nf .fi .if n \{\ .RE .\} .PP The \fIpolicyconfig\fR element must be present exactly once\&. Elements that can be used inside \fIpolicyconfig\fR includes: .PP \fIvendor\fR .RS 4 The name of the project or vendor that is supplying the actions in the XML document\&. Optional\&. .RE .PP \fIvendor_url\fR .RS 4 A URL to the project or vendor that is supplying the actions in the XML document\&. Optional\&. .RE .PP \fIicon_name\fR .RS 4 An icon representing the project or vendor that is supplying the actions in the XML document\&. The icon name must adhere to the \m[blue]\fBFreedesktop\&.org Icon Naming Specification\fR\m[]\&\s-2\u[6]\d\s+2\&. Optional\&. .RE .PP \fIaction\fR .RS 4 Declares an action\&. The action name is specified using the id attribute and can only contain the characters "[A\-Z][a\-z][0\-9]\&.\- ", e\&.g\&. ASCII, digits, period and hyphen\&. .RE .PP Elements that can be used inside \fIaction\fR include: .PP \fIdescription\fR .RS 4 A human readable description of the action, e\&.g\&. \(lqInstall unsigned software\(rq\&. .RE .PP \fImessage\fR .RS 4 A human readable message displayed to the user when asking for credentials when authentication is needed, e\&.g\&. \(lqInstalling unsigned software requires authentication\(rq\&. .RE .PP \fIdefaults\fR .RS 4 This element is used to specify implicit authorizations for clients\&. Elements that can be used inside \fIdefaults\fR include: .PP \fIallow_any\fR .RS 4 Implicit authorizations that apply to any client\&. Optional\&. .RE .PP \fIallow_inactive\fR .RS 4 Implicit authorizations that apply to clients in inactive sessions on local consoles\&. Optional\&. .RE .PP \fIallow_active\fR .RS 4 Implicit authorizations that apply to clients in active sessions on local consoles\&. Optional\&. .RE .sp Each of the \fIallow_any\fR, \fIallow_inactive\fR and \fIallow_active\fR elements can contain the following values: .PP no .RS 4 Not authorized\&. .RE .PP yes .RS 4 Authorized\&. .RE .PP auth_self .RS 4 Authentication by the owner of the session that the client originates from is required\&. Note that this is not restrictive enough for most uses on multi\-user systems; auth_admin* is generally recommended\&. .RE .PP auth_admin .RS 4 Authentication by an administrative user is required\&. .RE .PP auth_self_keep .RS 4 Like auth_self but the authorization is kept for a brief period (e\&.g\&. five minutes)\&. The warning about auth_self above applies likewise\&. .RE .PP auth_admin_keep .RS 4 Like auth_admin but the authorization is kept for a brief period (e\&.g\&. five minutes)\&. .RE .RE .PP \fIannotate\fR .RS 4 Used for annotating an action with a key/value pair\&. The key is specified using the key attribute and the value is specified using the value attribute\&. This element may appear zero or more times\&. See below for known annotations\&. .RE .PP \fIvendor\fR .RS 4 Used for overriding the vendor on a per\-action basis\&. Optional\&. .RE .PP \fIvendor_url\fR .RS 4 Used for overriding the vendor URL on a per\-action basis\&. Optional\&. .RE .PP \fIicon_name\fR .RS 4 Used for overriding the icon name on a per\-action basis\&. Optional\&. .RE .PP For localization, \fIdescription\fR and \fImessage\fR elements may occur multiple times with different xml:lang attributes\&. .PP To list installed polkit actions, use the \fBpkaction\fR(1) command\&. .SS "Known annotations" .PP The org\&.freedesktop\&.policykit\&.exec\&.path annotation is used by the \fBpkexec\fR program shipped with polkit \- see the \fBpkexec\fR(1) man page for details\&. .PP The org\&.freedesktop\&.policykit\&.imply annotation (its value is a string containing a space\-separated list of action identifiers) can be used to define \fImeta actions\fR\&. The way it works is that if a subject is authorized for an action with this annotation, then it is also authorized for any action specified by the annotation\&. A typical use of this annotation is when defining an UI shell with a single lock button that should unlock multiple actions from distinct mechanisms\&. .PP The org\&.freedesktop\&.policykit\&.owner annotation can be used to define a set of users who can query whether a client is authorized to perform this action\&. If this annotation is not specified, then only root can query whether a client running as a different user is authorized for an action\&. The value of this annotation is a string containing a space\-separated list of PolkitIdentity entries, for example "unix\-user:42 unix\-user:colord"\&. A typical use of this annotation is for a daemon process that runs as a system user rather than root\&. .SH "AUTHORIZATION RULES" .PP The Debian\-specific version of polkit documented in this manual page uses authorization rules compatible with polkit 0\&.105 and earlier, documented in \fBpklocalauthority\fR(8)\&. .PP A version of polkit compatible with newer upstream releases can be found in the polkitd\-javascript Debian package\&. .SH "AUTHOR" .PP Written by David Zeuthen with a lot of help from many others\&. .SH "BUGS" .PP Please send bug reports to either the distribution or the polkit\-devel mailing list, see the link \m[blue]\fB\%http://lists.freedesktop.org/mailman/listinfo/polkit-devel\fR\m[] on how to subscribe\&. .SH "SEE ALSO" .PP \fBpklocalauthority\fR(8), \fBpolkitd\fR(8), \fBpkaction\fR(1), \fBpkcheck\fR(1), \fBpkexec\fR(1), \fBpkttyagent\fR(1) .SH "NOTES" .IP " 1." 4 /usr/share/gtk-doc/html/polkit-1polkit-architecture.png .IP " 2." 4 GObjectIntrospection .RS 4 \%https://live.gnome.org/GObjectIntrospection .RE .IP " 3." 4 developer documentation .RS 4 \%http://www.freedesktop.org/software/polkit/docs/latest/ .RE .IP " 4." 4 /usr/share/gtk-doc/html/polkit-1polkit-authentication-agent-example.png .IP " 5." 4 /usr/share/gtk-doc/html/polkit-1polkit-authentication-agent-example-wheel.png .IP " 6." 4 Freedesktop.org Icon Naming Specification .RS 4 \%http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html .RE