run0

Posted Dec 18, 2025 13:25 UTC (Thu) by intelfx (subscriber, #130118)
In reply to: run0 by mchapman
Parent article: Conill: Rethinking sudo with object capabilities

> polkit agent is always registered against a particular process or logind session. When polkit needs to talk to an agent, it determines it according to the subject of the authorization: either that process itself (i.e. it's acting as its own agent), or the logind session that owns that process.

Ah, but the part about how to treat the "absence of a defined seat" was load-bearing in my reply.

> Where I have seen this break is when people start Tmux or Screen in their GUI session, then, at a later time, reconnect to that over SSH. When they reconnect to it they are effectively back in that GUI session, even if they aren't sitting at that seat.

In my personal setup, tmux server runs under `systemd --user`, outside of any defined session (and certainly outside of the session that owns seat0). Yet, when I run pkexec under tmux, it still gets ahold of the GUI authentication agent, despite having no reason to do so.

For instance, I went to specific pains to forward proper environment into each new tmux pane (such that when I create a new tmux pane from an SSH connection, that pane inherits specific environment variables of the SSH connection), and it inherits the SSH connection's $XDG_SESSION_ID. But none of this helps polkit to avoid contacting the GUI agent.

to post comments

run0

Posted Dec 18, 2025 13:32 UTC (Thu) by intelfx (subscriber, #130118) [Link] (1 responses)

> In my personal setup, tmux server runs under `systemd --user`, outside of any defined session

Slight correction: `systemd --user` is not outside of any defined session — it does, in fact, run under its own logind session (of class "manager"). But that does not materially change what I said (it's still not the session that owns seat0).

run0

Posted Dec 22, 2025 7:04 UTC (Mon) by mchapman (subscriber, #66589) [Link]

Ah, you're right. Polkit explicitly asks logind for the user's current "display" session if a session can't be identified for the process.

Perhaps it shouldn't do that, since it thwarts any attempt by that process to provide a fallback agent (which all the systemd tools do when they're using polkit).