On 1/4/21 8:47 AM, Emil Velikov via pacman-dev wrote:
Hello everyone,
For a while now I've been wondering about adding privilege elevation to pacman, or if you prefer to libalpm. In particular, one that uses polkit akin to systemd and various other tools.
The reason behind this is a multiple fold, but my main selfish wish is to get rid of yaourt. As you know, it is an "unsafe pacman wrapper" which is capable of a very basic elevation via sudo.
All of this seems like something I'm thoroughly uninterested in. As you say -- "akin to systemd". The `systemctl` tool, like pacman, has multiple modes of operation, some of which require root. In the event the user neglects to run "sudo systemctl ...", it will essentially say, from a user perspective, "hi, I notice you forgot to run me as root, but I need root. I will momentarily re-exec myself, using the polkit tool, to get root". Then it prompts for root, most likely using a GUI dialog that grabs control of your entire screen. 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. 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. I don't even see how this would let you get rid of yaourt, an AUR helper with the purpose of compiling AUR packages with one wrapper call. The simple solution is to take this code in src/pacman/pacman.c: /* check if we have sufficient permission for the requested operation */ if(myuid > 0 && needs_root()) { pm_printf(ALPM_LOG_ERROR, _("you cannot perform this operation unless you are root.\n")); cleanup(EXIT_FAILURE); } and modify it to ALPM_LOG_WARNING: you cannot perform this operation unless you are root. Rerunning {"sudo", "/proc/self/exe", argv...} and exec() that for auto-retry-as-root. This then adds a hard dependency on sudo instead of polkit...
Once that is complete, I have been itching to try and minimise the use/requirement of root, or as it's better known - apply the principle of least privilege.
Would either of the above be suitable for inclusion in pacman/libalpm? Having the thumbs-up, before writing and testing the code, would be appreciated. If it involves running the non-root parts as a system (not login) user,
But indeed we do, as Levente said, want to do separation of privileges. There ae a few things that don't *need* root, and operate on untrusted input, e.g. fields in unsigned databases, HTTP headers for http://mirror.randomuser.org/pub/archlinux/ and so on. Quite frankly, I don't believe these should be run as the invoking user either, but as a dedicated system user for privileged-but-not-root tasks. If we move GPGME verification of packages to a non-root user, that user better not be the current login user... The solution here is, I believe, to run pacman as root, but drop the EUID to the system account user "libalpm" for a bunch of things before we finally get to extracting package contents to "/". I don't see how polkit helps this goal. It assumes you have any intention of running some code as the login user; alternatively, it's just a very complex execlp("sudo", "sudo", "pacman", argv[1], argv[2], ...) then yes. i.e. the goal here is to make pacman more secure by *separation* of privileges. By personal preference, hopefully not polkit. :p Automatic *elevation* of privileges is not a goal, but if you implement the former in such a way that it also implements the latter, ok. ... Merely reimplementing an AUR helper's complimentary "detect whether the command line arguments need root, and choose to invoke pacman using sudo", but not actually making pacman more secure, makes me uneasy... ... and implementing it via polkit gets my NACK because I don't believe it's the job of a CLI tool to display GUI windows for authentication, and I'm not going to bite my tongue and accept it if it doesn't even give us FS#65401 but is solely to implement a yaourt feature. -- Eli Schwartz Bug Wrangler and Trusted User