run0

Posted Dec 16, 2025 15:34 UTC (Tue) by NYKevin (subscriber, #129325)
In reply to: run0 by intelfx
Parent article: Conill: Rethinking sudo with object capabilities

It is inherently hard to get this right in every case. But IMHO we could get reasonably close by having each agent report whether it is a GUI agent or a text-based agent (and/or its controlling terminal/session). Then you could have the requestor specify the same information, and filter the available agents to ones that are likely to be usable:

* If the requestor is a CLI app, and there is no $DISPLAY variable or similar, then contacting GUIs is probably a bad idea. It's probably also a bad idea to contact text-based agents with a different pty/tty, but that might be appropriate if there is no alternative (e.g. we're running under systemd or otherwise do not have a controlling terminal).
* Similarly, if the requestor is a GUI, contacting text-based agents is probably a bad idea.
* Finally, if we're a CLI app with a $DISPLAY, then it might be OK to contact GUIs on that specific display, as well as text-based agents on the same pty/tty. But it should not contact some random other session that has nothing to do with us.

to post comments

run0

Posted Dec 17, 2025 9:12 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Alternatively maybe some sort of approach similar to systemd-ask-password could be used where it is possible to call a command to get the prompt to your current terminal even if the automatic prompting is happening somewhere else?

run0

Posted Dec 17, 2025 13:58 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

There is the `wall` implementation. `systemd-tty-ask-password-agent` is not polkit-enabled to answer system requests as a user though. See https://github.com/systemd/systemd-ui/pull/7 for updating a simple GUI agent to modernity. A TTY agent would be nice to have too.