PolicyKit allow_active answers a session question, not an identity question
PolicyKit policies often grant privileged actions to an active local session. The allow_active=yes result can look like a statement about the logged-in user. It is better read as a statement about a client's session class. The distinction affects how administrators review actions and how applications request authorization.
What the policy value means
The PolicyKit reference manual defines three implicit authorization classes: allow_any, allow_inactive, and allow_active. allow_active applies to clients in active sessions on local consoles. Each can be no, yes, auth_self, auth_admin, or one of the keep variants.
yes grants authorization without a prompt. auth_self asks the owner of the session to authenticate. The manual warns that auth_self is not restrictive enough for most uses on multi-user systems and generally recommends auth_admin. Those values are policy defaults, and rule files can change the result for a subject and action.
The action definition also matters. allow_active=yes on a harmless status query is different from the same value on an operation that installs software or changes network configuration. The setting is not safe or unsafe by itself.
Session state is not tenant state
An active session may contain one user, a shared kiosk, a remote-support tool, or several applications acting for the same account. An application cannot infer that the person physically at the console requested a specific operation merely because the session is active. It still needs to bind the authorization decision to the action and the subject.
Review who controls the client connection. A local desktop application asking for a file-system operation has a different threat model from an unauthenticated web service asking PolicyKit to perform the same operation. A service that accepts network input should not be able to turn that input into a local active-session action without an explicit authentication step.
For sensitive operations, prefer auth_admin and rule files that inspect the subject and action. Avoid a broad rule that returns yes for every member of a group when only one action requires the grant. Keep the rule file under configuration management and review it whenever the mechanism changes.
The action definition is part of the code
The mechanism owns the action name, message, and default. The caller owns the request. A review should read all three together. Check that the action is called at the point where privilege is actually exercised, and that the message cannot be mistaken for a less sensitive operation.
pkaction lists installed actions. pkcheck can query an authorization decision for a process. Use these commands in a test environment to see how the policy evaluates the intended client, not just the administrator running the command.
pkaction --verbose pkcheck --action-id org.example.install --process "$PID" --detail key value The output can change with the session, the caller, and the rules loaded by policy. Record the client process and session used in the test.
Operational review
Policy files and rule files are code. Package updates can change defaults, and local administrator files can override them. Keep a copy of the effective files, record their hashes, and compare them after upgrades. Review the actions that return yes without authentication first.
Log the action identifier, result, and subject identity where the mechanism supports it. Avoid logging passwords, tokens, or full command lines. For incident response, a session's active state at the time of the request may no longer be available, so preserve the session classification and authorization result as part of the event record.
The implementation should also fail safely when the PolicyKit daemon or an authentication agent is unavailable. A timeout must not become an automatic grant. Test the failure path with the agent stopped and the action configured for auth_admin.
The useful question
Ask what authority the action represents, who can request it, which session class can satisfy it, and what evidence remains after the decision. allow_active=yes may be a reasonable answer for a narrow, local, low-impact action. It is a poor substitute for an identity or tenant check.
