[Feature Request] SudoLoop (and with Doas Support) in Paru Chroots

[ThisNekoGuy]

At the moment, with paru v1.8.2 - libalpm v13.0.1, the SudoLoop feature does not carry over into Paru's choots and, in addition, setting Doas as the authenticator in makepkg.conf causes all authentications to fail inside of Paru's chroots when used.

I'd like to request that these be implemented for consistency and peace of mind because, in larger AUR recompiles, this can be an issue. For example, I just came back after leaving for a while and a bunch of packages just didn't compile because I wasn't back in time to re-authenticate myself for sudo :/

[Morganamilo]

As far as I'm aware the chroot sets sudo no password so you should not be getting sudo prompts from within the chroot.

[ThisNekoGuy]

I'm looking at the sudoers file and that doesn't look to be the case; unless you mean for the root user, but that doesn't explain why I'm getting sudo prompts :/

## sudoers file.
##
## This file MUST be edited with the 'visudo' command as root.
## Failure to use 'visudo' may result in syntax or file permission errors
## that prevent sudo from running.
##
## See the sudoers man page for the details on how to write a sudoers file.
##

##
## Host alias specification
##
## Groups of machines. These may include host names (optionally with wildcards),
## IP addresses, network numbers or netgroups.
# Host_Alias    WEBSERVERS = www1, www2, www3

##
## User alias specification
##
## Groups of users.  These may consist of user names, uids, Unix groups,
## or netgroups.
# User_Alias    ADMINS = millert, dowdy, mikef

##
## Cmnd alias specification
##
## Groups of commands.  Often used to group related commands together.
# Cmnd_Alias    PROCESSES = /usr/bin/nice, /bin/kill, /usr/bin/renice, \
#               /usr/bin/pkill, /usr/bin/top
# Cmnd_Alias    REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff

##
## Defaults specification
##
## You may wish to keep some of the following environment variables
## when running commands via sudo.
##
## Locale settings
# Defaults env_keep += "LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET"
##
## Run X applications through sudo; HOME is used to find the
## .Xauthority file.  Note that other programs use HOME to find   
## configuration files and this may lead to privilege escalation!
# Defaults env_keep += "HOME"
##
## X11 resource path settings
# Defaults env_keep += "XAPPLRESDIR XFILESEARCHPATH XUSERFILESEARCHPATH"
##
## Desktop path settings
# Defaults env_keep += "QTDIR KDEDIR"
##
## Allow sudo-run commands to inherit the callers' ConsoleKit session
# Defaults env_keep += "XDG_SESSION_COOKIE"
##
## Uncomment to enable special input methods.  Care should be taken as
## this may allow users to subvert the command being run via sudo.
# Defaults env_keep += "XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
##
## Uncomment to use a hard-coded PATH instead of the user's to find commands
# Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
##
## Uncomment to send mail if the user does not enter the correct password.
# Defaults mail_badpass
##
## Uncomment to enable logging of a command's output, except for
## sudoreplay and reboot.  Use sudoreplay to play back logged sessions.
# Defaults log_output
# Defaults!/usr/bin/sudoreplay !log_output
# Defaults!/usr/local/bin/sudoreplay !log_output
# Defaults!REBOOT !log_output

##
## Runas alias specification
##

##
## User privilege specification
##
root ALL=(ALL) ALL

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL

## Uncomment to allow members of group sudo to execute any command
# %sudo ALL=(ALL) ALL

## Uncomment to allow any user to run sudo if they know the password
## of the user they are running the command as (root by default).
# Defaults targetpw  # Ask for the password of the target user
# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'

## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d

[Morganamilo]

It's installed as a sudoers.d file.

[ThisNekoGuy]

That folder's empty for me :thinking:

[Morganamilo]

Are you sure it's empty? Show what you're checking.

[ThisNekoGuy]

The sudoers.d folder inside of the chroot:

neko-san@ARCH /m/e/A/ParuChroot> doas ls ./root/etc/sudoers.d
doas (neko-san@ARCH) password: 
neko-san@ARCH /m/e/A/ParuChroot> 

[Morganamilo]

Packages are built in the user chroot not the root on. The sudoers file is installed there.

[ThisNekoGuy]

neko-san@ARCH /m/e/A/ParuChroot> doas ls ./neko-san/etc/sudoers.d/
neko-san@ARCH /m/e/A/ParuChroot> 

[Morganamilo]

That's where it should be. I don't know why your chroot is weird but it's there on mine.

[ThisNekoGuy]

Could you make a test chroot and see if it's still there for you?

[Morganamilo]

% sudo rm -rf /var/lib/aurbuild/x86_64/
% paru -Sa paru-git
% sudo ls /var/lib/aurbuild/x86_64/morganamilo/etc/sudoers.d
builduser-pacman

[ThisNekoGuy]

Ah, I think I know why now - it's my own fault

Since I use Doas, a long time ago I made a pacman hook that removes sudo.pacnew (thinking that it would be fine because some packages force the installation of sudo but I don't use it for the most part), and this carried over to the chroot and removed the pacnew file before it gets moved to the sudoers.d folder

Sorry about that

[ThisNekoGuy]

Nevermind, it's still happening even after undoing that; I remade the chroot, the file is there, and it still happens somehow :/

[Morganamilo]

Is makepkg configured to use doas? Seems as the chroot pulls the host makepkg.conf I imagine that would cause it to break.

[ThisNekoGuy]

Nope, I have the override for that commented out at bottom of the config:

#########################################################################
# OTHER
#########################################################################
#
#-- Command used to run pacman as root, instead of trying sudo and su
#PACMAN_AUTH=(doas)

I commented it out because of what I mentioned in the first post:

setting Doas as the authenticator in makepkg.conf causes all authentications to fail inside of Paru's chroots

[Morganamilo]

Send the full command output then.

[Morganamilo]

Also is sudo in ignorepkg?

[ThisNekoGuy]

I don't have anything set for ignorepkg

It'll take me a bit to grab the output for it to time-out; I'll post it asap

[ThisNekoGuy]

Got it, here: paruChrootOutput.log

It's lengthy so I made it a file to avoid making the post gigantic

[Morganamilo]

So it looks like the calls to makechrootpkg time's out because it internally calls sudo to do things. Looks like there may be no way around that and I'm not sure if the script will work if called as root.

[Morganamilo]

so makechrootpkg uses $SUDO_USER then $USER to become that user to run. So this would break if we called it with doas.

[Morganamilo]

Though as a hack I guess we could set SUDO_USER ourselves....

[Morganamilo]

Also makechrootpkg also expects a bunch of env vars persevered so maybe not...

[Morganamilo]

So probably never happening due to devtools. Closing until something changes there.

[ThisNekoGuy]

Do we have a related issue page about this over there? Nothing might be done about it if that project doesn't know :/

[Morganamilo]

My assumption is it would be rejected as devtools is just for arch packaging and also quite a mess. Last I checked it was using sudo to specify user and specify what env vars to keep. So if doas does not have the same flags then it won't be trivial either.

[ThisNekoGuy]

Would it make more sense to have Paru's own Rust interpretation of the process to avoid devtools's mess (possibly even as a crate), then? I'm not familiar with it, but I imagine having a newer/fresher and less tangled implementation might be the more prudent option in solving the issue? (Not that it's trivial, I imagine; just a thought)

[Morganamilo]

Not sure. I know aurutils has gone this way. But as makepkg is bash it would probably be best to write this sort of thing in bash so not sure if paru is suited. If alad would make "new devtools" it's own project that would be nice.