[pacman-dev] Adding privilege levitation to pacman

[Eli Schwartz]

On 1/4/21 6:31 PM, Emil Velikov wrote:
> On Mon, 4 Jan 2021 at 20:02, Eli Schwartz wrote:
>> Then it prompts for root, most likely using a GUI dialog that grabs
>> control of your entire screen.
>>
> AFAICT if there is a GUI agent installed and can be used it will.
> For example; having the gnome agent in a normal session - GUI. In a
> TTY or over SSH - the TTY agent will be displayed.
> 
> In other words - it depends on what the user has installed and it's
> consistent with their overall experience.
> 
> Wrt grabbing the entire screen - that depends on the agent implementation.

Right, this is precisely the problem. There's no concept of "well, maybe 
the authentication needs of a CLI program are different from the needs 
of a GUI program", polkit agents merely care if you're booted into a 
display server or a tty.

This is bad because user experiences should prefer "good" > "consistent".

Trust me, I've experienced the polkit experience of

$ pkexec bash
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/bash' as the super user
Multiple identities can be used for authentication:
  1.  eschwartz
[...]
Choose identity to authenticate as (1-X):

Unfortunately, the only way to get this "good" experience in a graphical 
terminal emulator running inside your WM, is to use an environment where 
you cannot get the GUI application menu or program windows to display 
the GUI polkit prompt they *should* have. :(

>> Under the hood, it is actually depending on dbus and a javascript engine
>> in order to pass messages to daemons that do "everything which needs
>> root", which in pacman's case is... essentially everything, once you're
>> in "install and remove packages" mode.
>>
> The dbus part is spot on, although there was no JS engine last time I've looked.

polkit uses Mozilla Firefox's javascript engine to write and interpret 
polkit rules. It's part of the /usr/lib/polkit-1/polkitd daemon which 
you communicate with over the bus, not the part your application links to.

>> But the user experience of using polkit here is pretty simple: it lets
>> you forget to use "sudo" and not need to re-run after an error.
>>
> Whether there is a timeout (after a successful or failed attempt) is
> user configurable IIRC.

This is unrelated to what I said? I merely drew a comparison between 
running `sudo pacman -Syu` and `pacman -Syu`, or running `sudo systemctl 
start ...` and `systemctl start ...`, that in each of the latter cases, 
you'd get an error message from pacman/systemctl itself, unless polkit 
avoids the error message by turning it into a "try to become root" prompt.

>> and exec() that for auto-retry-as-root. This then adds a hard dependency
>> on sudo instead of polkit...
>>
> One could detect the presence of sudo/pkexec early and opt for
> each/either one as you pointed out, finally bailing out as originally.

Maybe if we permitted configuring the chosen tool of elevation in 
pacman.conf for the user's choice of sudo, su, pkexec, or doas.

In fact, I have WIP code to do precisely this AUTH_CMD sort of setting 
in makepkg (which currently hardcodes sudo falling back to su in order 
to implement the run_pacman function used in makepkg -s, -i, -r options).

> Not entirely sold that starting as a root is a good idea. I've seen
> far too many horror stories while looking at Xorg.
> Will try and dig out some information how other package managers are
> handling it.

"xorg is bad implementation, therefore every high-level, medium-level, 
and low-level goal it ever tries to do is bad even for clean-room 
implementations of similar concepts" is not an argument.

In fact, let's go one step further: "xorg is bad, therefore something 
else is bad too" isn't an argument. If you want me to accept something 
is bad, you'll need to come up with a much better argument that has 
topical relevance and isn't based on random anecdotes from a program 
whose single overriding problem across the board is lots of instances of 
"the specific code implementation they used for XYZ is a bad coding 
style for doing XYZ".

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20210104/d1bf6f85/attachment.sig>