Yay: Allow installing AUR packages as root with yay

[Menci]

Affected Version

yay v9.2.1 - libalpm v11.0.3

Issue

Building AUR packages with root IS dangerous, but SHOULD be allowed if someone know the risk. It is very inconvenient to run yay on a system without an non-root user. Consider adding a item to the configure file to allow root.

Currently my workaround is creating a user for yay, adding it to sudoers with NOPASSWD then alias yay="sudo -u yay yay".

Steps to reproduce

With root, execute yay -S caddy (or any other AUR packages)

Output

==> Refusing to install AUR Packages as root, Aborting.

[Jguer]

https://wiki.archlinux.org/index.php/Makepkg#Usage
https://lists.archlinux.org/pipermail/pacman-dev/2014-March/018911.html

Users who have no access to a regular user account should run makepkg as the nobody user.

It's not a yay consideration, it's a makepkg consideration. All yay could do is the same workaround you're doing (or always run as nobody, but then, problems will arise elsewhere)

[jonathonf]

It is very inconvenient to run yay on a system without an non-root user

In what situation are you running yay on a system without a non-root user?

[Menci]

@jonathonf For example a personal server. All users are system user except root.

[jonathonf]

All users are system user except root.

But then you still have non-root users. Also, performing day-to-day tasks as root is very bad practice.

a personal server

It would be very rare to run a server with only the root user, and you certainly wouldn't use the AUR directly on a server of any value.

I don't know what AUR packages you'd want to install on a root-only server?

I just don't see the use-case for this.

[polygonalenippel]

Building AUR packages with root IS dangerous, but SHOULD be allowed if someone know the risk.

That is, if you know the risk.

• If you do, then you should know what you got on your plate. We can't state enough that running foreign packages without inspection, as root, is a bad idea and should be warned against.

• If you happen to be root, and forgot, it is a good reason to warn against.

• If you happen to be root and have no idea what you're doing, then this is perhaps the only (subtle) hint you should stop what you're doing to figure out why this maybe isn't such a good idea, from a security perspective.

Therefore, your issue is a bad idea and you should reconsider your practices. Your proposal of

Consider adding a item to the configure file to allow root.

only advocates bad practices. @Menci

[naiveai]

So instead, I create a non-root account, give it basically the same privelges and have almost identical risks, and just run yay from there. It doesn't really accomplish much from a safety perpsective. If people are running untrusted packages willy-nilly, it doesn't really matter whether or not it's technically on root for them to mess up their system.

[polygonalenippel]

So instead, I create a non-root account, give it basically the same privelges and have almost identical risks, and just run yay from there. It doesn't really accomplish much from a safety perpsective. If people are running untrusted packages willy-nilly, it doesn't really matter whether or not it's technically on root for them to mess up their system.

What's the point of putting fences on balconies? If people wanted, they should be able to take the risk of smashing into the ground without a fence. So instead, I unscrew the posts, make it basically the same height and have almost identical risks, and just sit right there. It doesn't really accomplish much from a safety perspective. If people are sitting on balconies willy-nilly, it doesn't really matter whether or not they have fences stopping people from letting them fall off their balcony.

[polygonalenippel]

Sure, uncle Dennis might throw me off my balcony if he's on a massive drunk, though he might be the only one. What about stormy weather when I'm sitting on my small chair? Wouldn't having a fence be better after all?

No one can stop you from doing such practices, though with power comes responsibility. If you're a constructor of balconies for all kinds of apartments, and you have the choice of putting up a fence, wouldn't you put those in there as well? Perhaps another constructor would get the deal instead of you because most people would rather prefer fences out of common sense?

@naiveai , why don't you just construct your own barebones clone, cd, makepkg branded balcony instead of convincing other residents to remove their fences?

[Morganamilo]

Consider you typo $pkgdir, you've now bypassed the packaging step and accidentally inserted files right into your system that pacman doesn't track. And you've probably not even noticed.

The general philosophy of "don't give things more permission than it needs" is not just about malicious intend.

So instead, I create a non-root account, give it basically the same privelges

And your solution is actually still protected against this problem.

[madobet]

It is very inconvenient to run yay on a system without an non-root user

In what situation are you running yay on a system without a non-root user?

When you are in a "fake-root". I can not use yay in JuNest, even if it provides a modified makepkg.

[Depau]

Hi,
would it be considered to implement a workaround such as pikaur's?
https://github.com/actionless/pikaur/blob/9927f5810b1e135e141c764b64486efcd14d8dc8/pikaur/core.py#L181

Basically it uses systemd-run to run makepkg in a transient non-root environment.

My use case would be to run yay from ansible-aur on hosts that are configured to ask for root password.

[jonathonf]

When you are in a "fake-root". I can not use yay in JuNest, even if it provides a modified makepkg.

You don't need this any more - JuNest has a new BubbleWrap-based backend which provides a "fake user" environment with "fake sudo" as needed.

yay now works perfectly under junest ns

[joejulian]

In what situation are you running yay on a system without a non-root user?

Building a docker image, running yay from a Dockerfile.

[jonathonf]

Pretty sure Dockerfiles support running commands as non-root users:

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user

[joejulian]

That's only 1/3 of the answer. The rest of the answer requires installing sudo into the container image, and adding a sudoer configuration, increasing the size of the container image and installing unnecessary security privilege escalation tools.

[jonathonf]

The page says:

Avoid installing or using sudo

so I'm not sure what you're doing which requires it. However, that's a Docker issue rather than a yay issue.

[madobet]

When you are in a "fake-root". I can not use yay in JuNest, even if it provides a modified makepkg.

You don't need this any more - JuNest has a new BubbleWrap-based backend which provides a "fake user" environment with "fake sudo" as needed.

yay now works perfectly under junest ns

Really? Thanks a lot 👍

[AladW]

installing unnecessary security privilege escalation tools.

And the proposed solution is to run arbitrary code from the internet as root instead 😂

Docker's documentation is pretty good, read it. The issue is installing dependencies: be it with makepkg -s which runs sudo pacman -S, or with yay which (probably) runs sudo pacman -U.

What you could do instead is get the list of dependencies as the unprivileged user, and then install them as root with pacman. But unless this has changed, yay can either only:

1. do a dumb fetch of a single PKGBUILD;
2. build and install a full dependency chain of PKGBUILDs.

I'd suggest to get something inbetween 1 and 2 rather than bolt on systemd machinery only for a niche use case.