[pacman-dev] Adding privilege levitation to pacman

[Emil Velikov]

On Tue, 5 Jan 2021 at 04:00, Eli Schwartz via pacman-dev
<pacman-dev at lists.archlinux.org> wrote:
>
> 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. :(
>
I see what's happening - personally the polkit CLI experience is
perfectly reasonable. Seems like I'm a minority.

> >> 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.
>
You're spot on. There was a proposal to switch to lua some 5+ years
ago and seemingly that never happened.

> >> 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.
>
I see - my bad.

> >> 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).
>
Such would be perfect IMHO.

> > 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".
>
I'm not claiming that every solution is bad because I saw one which has bugs.

Merely pointing out that the combinatorial explosion and hence
complexity required is much greater with the single binary using
"start as root" approach. And with greater complexity - a greater
probability for bugs etc.

Huge thanks to everyone for the input in this thread. I did not expect
it to be as popular :-)

Thanks
Emil