On Tue, 5 Jan 2021 at 04:00, Eli Schwartz via pacman-dev <pacman-dev@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