Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#43302 - [pacman] provide workaround for removing --asroot from makepkg

Attached to Project: Pacman
Opened by brent saner (sanerb) - Friday, 02 January 2015, 07:05 GMT
Last edited by Allan McRae (Allan) - Friday, 02 January 2015, 09:34 GMT
Task Type Bug Report
Category makepkg
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version 4.2.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

In pacman 4.2.0, makepkg's --asroot option was removed entirely. This, unfortunately, breaks operation across my build system fleet as it now severely complicates testing e.g. both building and testing of packages from PKGBUILDs. Sudo is not run on these servers, and because operations are done en-masse it makes entering 20-some unique passwords incredibly tedious. While I understand the intent of removing the option, and applaud the motivation behind it, it unfortunately breaks a lot of usage in how makepkg was implemented; especially in AUR helpers (as it affects yaourt, packer, pacaur, etc.) and such. Because of this, I believe that removing --asroot could be considered a regression, despite the progressive intent behind it.

I don't believe in trying to protect users from stupid mistakes they want to intentionally make in the first place (i.e. it's to be assumed that if makepkg is called with --asroot, then it's because the user *really does* want to build as root for whatever reason). I believe that *intentionally preventing* the usage of makepkg as root is against the Arch Way (https://wiki.archlinux.org/index.php/The_Arch_Way#User-centric - "Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system.").

What I instead would like to suggest is provide a method for makepkg to automatically drop privileges to the "nobody" user for the actual build and possibly packaging, if run as root, as the "nobody" user is ubiquitous across all systems, rather than spitting out an error and dying. Perhaps even bring back --asroot, but as a dummy function to avoid the need for AUR helpers and the like to remove it from their sources. I find this to be a clean, simple, elegant, and effective method that will keep the benefits of removing the actual hackery behind --asroot, but still allowing current implementations of makepkg to still work correctly.

Alternatively/in addition, it'd be great to have a "MKPKG_USER=" directive in /etc/makepkg.conf that would assume privileges of this specified user if called with root privileges.

Steps to Reproduce:
N/A
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 02 January 2015, 09:34 GMT
Reason for closing:  Won't fix
Comment by Allan McRae (Allan) - Friday, 02 January 2015, 08:15 GMT
Pacman is not only used by Arch Linux - so arguments involving the Arch Way do not matter. And the Arch Way is whatever its developers decide (not matter what users write in the wiki...).


Why doesn't your build system just drop privileges to the nobody user?
Comment by brent saner (sanerb) - Tuesday, 06 January 2015, 18:31 GMT
"Why doesn't your build system just drop privileges to the nobody user?"

Well, I do suppose I don't have a choice but to spend the man hours to do this, aside from rolling an entire fork of pacman, now- considering this is closed as WONTFIX.


"Pacman is not only used by Arch Linux - so arguments involving the Arch Way do not matter. And the Arch Way is whatever its developers decide (not matter what users write in the wiki...)."

I understand what you're saying but think you miss the spirit of what I'm saying. Do you mean to say that in your foresight, you see *no* possible value in implementing the suggested fixes I mention in the original summary? Not even (*especially* not even) from an Arch developer standpoint? I do find that hard to believe. Further, is not Arch considered the first point in Pacman development? I'm not trying to start a philosophical discussion here, but saying "Pacman is not only used by Arch Linux - so arguments involving the Arch Way do not matter" is like saying "The Linux kernel is not only used by Linus, so his input doesn't matter." It seems a bit silly to me that that would be the reasoning behind closing this as WONTFIX.

I just don't understand the aversion to letting users make (what one might consider) stupid mistakes. This is why --force flags exist on countless of core GNU userspace utilities- because sometimes, the stupid way is the best way.
Comment by brent saner (sanerb) - Tuesday, 06 January 2015, 19:56 GMT
Actually, the head of Arch development, it seems, phrakture, even links to and summarizes the Arch Way on http://phraktured.net/:

___________________________________
Archway

The Arch Way is a document that has been around for some time. It defines the core Archlinux philosophy - what makes us tick.

Here is my take on that document. My version of what we provide the user.

In short, the Arch Way is about simplicity and giving control to the user. Keeping things simple, and agile.

Arch is lightweight and simple, like clay - able to be molded by the user as they choose.

Arch is not a distribution made for "user friendliness". It is a distribution designed to be a platform - a "base" for the user to do what they want. This means that we don't try to force a user's hand into our way of doing things, with our configuration tools, and our ideas. It should be about their ideas.

It is important who controls the system here: the user. Developers suggest things, and push in certain directions, but let the user do as they wish.

Arch is a base for anyone to make into whatever they see fit. Arch is a tool.

Use it well

Furthermore, the driving philosophy behind Arch is provided in this document. Here, again, is my take on this (really just reworded).

Keep It Simple, Stupid: A simple design is usually the most elegant (See also Occam's Razor)

'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap.

Relying on complex tools to manage and build your system is going to hurt the end users. Maintenance and upgrading should be an active process, not a passive one.

"If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding.

We can't help you. Yes this is a philosophical point. Every Arch user is expected to be able to help themselves - to be able to look up information, configuration files, bugs, etc. You're expected to be able to do a little research when you have a problem. Teach a man to fish, and all that.

We are, above all, a community oriented distro. Contributions and effort from the end users should never be discouraged.

Unlike other distros, Arch is not primarily concerned about the user. The user is important, sure, but most important are simplicity and elegance. The user is important as long as it does not interfere with these doctrines.

"It is what you make it" -- Judd Vinet
___________________________________
(http://phraktured.net/arch-way.html)


Removing --asroot, and refusing to provide an alternative, defies the following points- and remember, this is Aaron Griffin's *own phrasing*:

"In short, the Arch Way is about simplicity and *giving control to the user*. Keeping things simple, and agile." (emphasis added)

"Arch is not a distribution made for "user friendliness". It is a distribution designed to be a platform - a "base" for *the user to do what they want*. This means that *we don't try to force a user's hand into our way of doing things*, with our configuration tools, and *our ideas. It should be about their ideas.*" (emphasis added)

"*It is important who controls the system here: the user*. Developers suggest things, and push in certain directions, but *let the user do as they wish.*" (emphasis added)

So, if this is stated by Aaron Griffin, the *lead developer*, then why do you state that is not the "Arch Way"?

As such, I am requesting re-open as:

-this is a regression in functionality
-the closing is a clear attempt to brute your decision into the functionality of end-user implementation

I highly recommend and encourage you to discuss this with other Arch developers, including Aaron "phrakture" Griffin, before closing again as it does appear that I provided a suggestion that will make everyone happy (it will allow legacy --asroot function to be removed, yet have the functionality itself still present), yet it's being closed as WONTFIX.
Comment by Aaron Griffin (phrakture) - Tuesday, 06 January 2015, 21:08 GMT
As I am being pulled into this argument as well as messaged on IRC about this, I will add my comments:

* Removing --asroot does not protect a competent user from mistakes, it prevents malicious or poorly written third party scripts from disrupting your system
* If it takes "many man hours" to make your build system drop to a non-root user, your build system is shit
* You can always maintain your own fork of makepkg like a *competent linux user* should
Comment by Allan McRae (Allan) - Tuesday, 06 January 2015, 22:30 GMT
I can fix your build system:

sed "s#makepkg#su -c nobody makepkg#" /build/script

and for interactive use...

alias makepkg="su -c nobody makepkg"

Comment by l3iggs (l3iggs) - Tuesday, 06 January 2015, 22:45 GMT
Dear pacman/makepkg devs,

The regression that is the removal of the --asroot option is frustrating for me when trying to use `makepkg -si` in an unattended way in my docker container (where every command is generally run as the root user).

Please reinstate --asroot and let me decide for myself what risks I would like to take with my hardware and software instead of making those decisions for me.
Comment by Allan McRae (Allan) - Tuesday, 06 January 2015, 23:11 GMT
No.
Comment by Mathias Steiger (mathiassteiger) - Saturday, 24 January 2015, 18:14 GMT Comment by Allan McRae (Allan) - Sunday, 25 January 2015, 00:08 GMT
Run makepkg sudoing to the nobody user and give the nobody user permission to use pacman without a password. Then you never need to type your password.
Comment by Noah Brecht (NoahB) - Thursday, 09 February 2017, 17:25 GMT
Here's my take on this:

I completely agree with the motives behind removing --asroot. Running as 'root' is dangerous as the build process can add/change/delete any part of your system. The build process does not require 'root' access, only the install.

I do not believe that --asroot should be removed. I consider it a regression, and believe that it contradicts the 'Arch Way.' I understand that there is little to no benefit in --asroot (I have never had to use it), and that it is a security risk. I see no benefit in --asroot, but the 'Arch Way' states that the user should have full control of their system. Because 'makepkg' is part of the core of the build system, I believe it should follow the 'Arch Way', i.e. Let the user decide how to run it. The user should be allowed to make whatever decision they want to make with their system, even if it will destroy their system (pacman -R systemd; reboot). Considering that --asroot has to be manually added to the command line, it should be clear the the user *wants* to run --asroot even though it is a security risk.

Loading...