Run makepkg as non-root when yay is run with sudo or as root

[lectrode]

Currently in apacman you have the ability to install or update AUR packages as root. It gets around the inability to run makepkg as root by creating a new user ("aurbuild") and running makepkg as that user.

Snippet from apacman code for reference:

  # Installation (makepkg and pacman)
  rm -f *$PKGEXT
  if [[ $UID -eq 0 ]]; then
    id aurbuild >/dev/null 2>/dev/null || useradd -r -d /var/empty aurbuild
    mkdir -p /var/empty/.gnupg
    chown -R aurbuild:aurbuild . /var/empty/.gnupg

    if [[ $validpgpkeys ]]; then
      su aurbuild -c "gpg --refresh-keys ${validpgpkeys[*]}"
      keyfound=$(su aurbuild -c "checkpgpkeys ${validpgpkeys[*]}" 2>/dev/null)
      if ! [[ $keyfound ]]; then
        askpgpkeys "${validpgpkeys[*]}"
        su aurbuild -c "addpgpkeys ${validpgpkeys[*]}"
      fi
      su aurbuild -c "makepkg $MAKEPKGOPTS -f"; buildcheck=$?
      [[ $keyfound ]] || su aurbuild -c "removepgpkeys ${validpgpkeys[*]}"
      [[ $purgekeys ]] && [[ $keyfound ]] && su aurbuild -c "removepgpkeys ${validpgpkeys[*]}"
    else
      su aurbuild -c "makepkg $MAKEPKGOPTS -f"; buildcheck=$?
    fi

This has proven to be immeasurably valuable in my work, and the main reason I'm still using apacman instead of any other AUR package manager (despite it's apparent abandonment). This functionality allows me to completely update the systems I manage remotely without having to touch each one individually, save for the occasional manual update steps, which I'll discover and script before updating the rest of the systems.

Would it be possible to add this functionality to yay?

[Jguer]

It is possible to implement this functionality in yay. This would involve allowing yay to run as root so I'll still have to go over the current logic to see what else will get broken by this.

[lectrode]

That would be awesome. I'm happy to test any changes and provide feedback as well.

[julianxhokaxhiu]

I really would like to have this implemented. It was really an awesome feature with apacman, and as long as I used it in those last 2 years, I never had a draw-back.

[takaomag]

+1

[AladW]

The hard part here is that you need to reimplement makepkg -s. apacman didn't care about that since it never cared about being reliable in any expect (such as reliably solving dependencies). The easy way is using devtools, since makechrootpkg -U already exists.

[Morganamilo]

We already do the dep solving ourselves, so we don't user -s. The main thing I have against a chroot is the extra space it will take up. Not just because the chroot but because you need to keep packages in cache to feed in to the chroot.

[AladW]

I'm not sure why anyone would replicate makepkg -s if you're not running as root, but I guess there's no other hurdles. (I'm also not sure why you'd want to remove packages you've just built, because there's then no way to recover - other than a rebuild - if the installed files are corrupted in any way)

[Morganamilo]

I'm not sure why anyone would replicate makepkg -s

It's re implemented because there's no way to get makepkg to nicely respect pacman options such as --dbonly Plus we already resolve all the AUR deps, handling repo deps is not that different.

I'm also not sure why you'd want to remove packages you've just built, because there's then no way to recover - other than a rebuild - if the installed files are corrupted in any way

That's true but I hope a installed package getting corrupted isn't the most common of things.

if you're not running as root, but I guess there's no other hurdles.

For me the main hurdle is a thinking up a decent implementation. Pikaur has its dynamic users thing which is cool but I don't know if I want to add a dependency on systemd. A simpler way that could work is to, chown nobody; su nodbody; makepkg; chown root.

The thing is, running as root is going to change the config file and cache location from your home directory to /root. Which is good for people running in a container or whatever where there is only a root account. But the users who accidentally call sudo yay might be a little confused when things don't work as they expect.

[AladW]

For the last point, you could default to SUDO_USER for unprivileged operations and configuration files? Package installation et al would be handled as root (to use sudoers in avoiding sudo prompts rather than a sudo -v loop)

edit: the above suggestion assumes writing inappropriate values in the configuration file wouldn't cause yay to do funny things while elevated.

[Morganamilo]

Yeah but then that wouldn't work for real root accounts. I guess just default to nobody if SUDO_USER is unset.

[pecigonzalo]

What about using: https://wiki.archlinux.org/index.php/Systemd-nspawn ? instead of chroot directly? I think using chroot for builds is the right approach to isolate from the host environment.

[AladW]

makechrootpkg has been using systemd-nspawn for a long time. It doesn't really isolate though, since it runs makepkg twice - once on the host (to retrieve sources) and once in the container (to do the actual build).

[julianxhokaxhiu]

Is there any update related to this issue? Is there help still needed?

Maybe could we integrate this pattern instead which is also suggested in the makepkg wiki?

http://allanmcrae.com/2015/01/replacing-makepkg-asroot/

[Jguer]

I haven't worked on it and I think @Morganamilo neither. Would like to see this fixed though

[AladW]

The simplest way is create a new unprivileged user with /sbin/nologin as login shell, which you grant sudoers access to pacman. You can then keep the configs and whatever in that user's home directory, e.g. /var/cache/something.

It's essentially what allan's blog describes, but with a separate isolated user rather than nobody.

[njam]

As a workaround you can use pikaur to install AUR packages as root. It uses "systemd-run" to drop privileges.

(cross-posting from #1026 (comment))

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[julianxhokaxhiu]

Is it possible to implement @njam suggestion on yay? It would be a great improvement. Thank you in advance.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lectrode]

Would still like to see this implemented

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[julianxhokaxhiu]

Nope, not today.

[Jguer]

Best effort implementation in #1595 , some improvements should be possible after testing