Pacman 7.0 DownloadUser, Sandbox, with a local AUR repo

NuSkool · 2024-09-17 06:05:12

I've had a local AUR repo set up for years where I build AUR packages in an nspawn container, copy/enter the built packages to host local AUR repo/DB using a bash script.
The local AUR repo resides under home, with the directory and all contents having $USER:$USER permissions.
The nspawn container has a dedicated build user setup and contains a local AUR repo setup as well.

I'm a bit confused on some details regarding the new downloading and sandbox features in pacman. Testing in a duplicate MV of my setup, first I applied the recommended changes from the news coverage to both the local and nspawn AUR repos.

For users with local repos however this might imply that the download user does not have access to the files in question, which can be fixed by assigning the files and folder to the alpm group and ensuring the executable bit (+x) is set on the folders in question.
$ chown :alpm -R /path/to/local/repo

However, I had issues (paraphrasing, didn't save them) errors about newly built packages residing in the local AUR repo/database not being accessible (permission?) to install that were in fact available.

I continued messing around a bit to figure out what seems to work for my setup with the following pacman.conf. I have set the default commented out '#DisableSandbox', and commented out '#DownloadUser = alpm', which then uses the current $USER. root.

Finally I cloned a new VM to start fresh and make sure my findings actually worked. Seems everything is good so far.

man pacman.conf:

DownloadUser = username
Specifies the user to switch to for downloading files. If this config option is not set then the downloads are done as the user
running pacman.
DisableSandbox
Disable the default sandbox applied to the process downloading files on Linux systems. Useful if experiencing landlock related
failures while downloading files when running a Linux kernel that does not support this feature.

Default pacman.conf:

DownloadUser = alpm
#DisableSandbox

My questions are:

1) Is there both a user:group called 'alpm' used by pacman? Are they setup system level by pacman? Yes

2) Is there any advantages or drawbacks to using '$USER:$USER' over 'alpm:alpm' or? $USER is not used, it falls back to root

3) Since I didn't uncomment 'DisableSandbox', it's still in use but using my $USER:$USER rather than alpm:alpm? root user is used when commenting out DownloadUser in pacman.conf

4) IIRC, pacman used to download packages as root, and guessing these new features add a level of security? yes

I'd be thankful to learn any (official) details about this stuff and how it pertains to my setup.

New findings 2024-09-26 Additional info: https://bbs.archlinux.org/viewtopic.php?id=299556

Last edited by NuSkool (2024-09-26 16:52:11)

seth · 2024-09-17 06:46:34

pacman used to download packages as root, and guessing these new features add a level of security?

https://archlinux.org/news/manual-inter … -required/

In case you've troubles w/ that, https://bbs.archlinux.org/viewtopic.php?id=299394

NuSkool · 2024-09-17 18:49:35

I did a little more exploration and can now answer one of my previous questions. I'll continue to edit post them here in case others may find the info useful.

1) Is there both a user:group called 'alpm' used by pacman? Are they setup system level by pacman?

1) Yes, pacman creates both user and group 'alpm:alpm' system wide if you run the default pacman.conf file. If you comment out 'DownloadUser = alpm', before running pacman, it does not.

2) Is there any advantages or drawbacks to using '$USER:$USER' over 'alpm:alpm' or?

2) Drawbacks, because your user account undoubtedly has permissions exceeding those of user alpm.

Additional info unrelated to my previous questions:

In my persistent AUR package building nspawn container using default pacman.conf, I get the following error installing an AUR package, although it will install the package. This with kernel linux 6.10.10.arch1-1 so this must be an nspawn related deal.

error: restricting filesystem access failed because landlock is not supported by the kernel!

New findings 2024-09-26 Pacman sandboxing can be used in nspawn containers. See towards bottom of: https://bbs.archlinux.org/viewtopic.php … 3#p2198823

To eliminate this error, I commented out # DownloadUser = alpm in the nspawn containers pacman.conf.

The following error is when trying to install an AUR package in host using the default pacman.conf. Pacman refused to install the package in this case. The local AUR repo is setup under home, with $USER recursively as owner, and 'alpm' recursively as group.

error: failed retrieving file 'aurutils-20-1-any.pkg.tar.zst' from disk : Couldn't open file /home/jeff/.cache/aurch/repo/aurutils-20-1-any.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)

Commenting out, ie # DownloadUser = alpm' in pacman.conf solves the above issue on my system. In this case according to man pacman.conf, DownloadUser would be/use the current user running pacman.

I believe if I were to move my local AUR repo out of my home dir, things would work without commenting out DownloadUser = alpm . However in my case I prefer to keep it as is. Not sure how much less secure this is, so worst case it will not take advantage of the new DownloadUser and Sandbox features.

I've also discovered regarding my local AUR repo, after I ran per the news, $ chown :alpm -R /path/to/local/repo, I verified everything was set as expected. After using my AUR script, the user:almp setting changed back to user:user for the DB's, aur.db.tar.gz' and 'aur.files.tar.gz.

My findings on permissions.

In host* system I added alpm group to my user, then allow alpm read permission on my home directory.

I read that the AUR repo directory needs the x bit set on it, and mine was already set, along with all the subdirectories from /home except my home directory. I believe this was causing the error above before I commented out alpm in pacman.conf .

Before changing home permissions:

drwxr-xr-x  4 root root 4.0K Sep  5 22:37 home
drwx------  9 jeff jeff 4.0K Sep 18 00:52 jeff
drwxr-xr-x  8 jeff jeff 4.0K Sep  6 00:30 .cache
drwxr-xr-x  4 jeff jeff 4.0K Sep  6 00:30 aurch
drwxr-xr-x  2 jeff alpm 4.0K Sep 17 15:56 repo

Changes to home:

drwxr-x--- 9 jeff alpm 4.0K Sep 18 02:27 jeff

$ stat /home/jeff
  File: /home/jeff
  Size: 4096          Blocks: 8          IO Block: 4096   directory
Device: 8,4    Inode: 130561      Links: 9
Access: (0750/drwxr-x---)  Uid: ( 1000/    jeff)   Gid: (  970/    alpm)
Access: 2024-09-18 01:21:08.672473024 -0700
Modify: 2024-09-18 01:20:41.882418637 -0700
Change: 2024-09-18 01:20:41.882418637 -0700
 Birth: 2024-09-05 22:37:48.773402067 -0700

I'd think this may be a better solution than not using user alpm .

I guess this change opens up my home directory to potential malicious 'read only' activity from user alpm or pacman? I live on the edge, no fear and willing to take a reasonable risk! lol

Appreciate any feedback if any of what I've written here seems OK or if it's complete bullshit please call me out. I'm well aware I know just enough to be a danger to myself and potentially any readers.

* = host to my persistent AUR nspawn building container.

Pre TLDR:

So recapping, I ended up commenting out # DownloadUser = alpm in pacman.conf, in both the nspawn container, and the host system. Everything works as expected without errors. Also note this was for two different errors (above). In the nspawn container, it printed an error but did install the package. In the host system, it printed the error and would not install the package.

I am thinking that by using current user as DownloadUser it is still using the sandbox feature, but as $USER rather than a more restrictive permissions alpm user.
If this is true, this may be better a better option than disabling sandboxing all together (would DownloadUser then be root?) by uncommenting #DisableSandbox ?

Then I changed the permissions as written above, and went back to the default use of alpm user DownloadUser = alpm in pacman.conf.

Final TLDR:

Revised/condensed the info I wrote about above into the following commands and edit.

$ chown :alpm "${HOME}"
$ chmod 750 "${HOME}"
$ sudo chown -R :alpm "${HOME}/.cache/aurch/repo"

In AUR nspawn container, comment out the following line in /etc/pacman.conf:

# DownloadUser = alpm

Based on my findings, I believe the info provided in Arch Latest News https://archlinux.org/news/manual-inter … -required/ regarding "users with local repos" is incomplete for those with a repo residing under their home directories. That said as mentioned in a seth's reply above, he provided a link to a thread related to the $HOME directory permissions and potential workarounds/solutions.

In my opinion, the best solution if you have a local repo under home is to relocate it somewhere outside $HOME, and possibly set up a symlink back to the original repo location. I chose to keep my local repo under home, (due to my AUR scripts) and allow user alpm read access to my home directory.

As for landlock support in an nspawn container, I'd like to learn more but came to a dead end for info. I'm also still uncertain about the relationship between DownloadUser, Sandbox, and if falling back to $USER for DownloadUser offers any benefits of the new pacman features in my nspawn container.

Additional show stopping finding:

On a recent Arch install, the above applied three commands and edit didn't work with pacman printing the error:

error: failed retrieving file 'pkgbrowser-0.28.1-3-x86_64.pkg.tar.zst' from disk : Couldn't open file /home/jeff/.cache/aurch/repo/pkgbrowser-0.28.1-3-x86_64.pkg.tar.zst
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.

I found the ACL settings on $HOME directory were blocking group alpm access. To find/fix this issue I ran the following commands. I've never used or set ACL's, so my guess is the default setting has changed for $HOME over time. This may be set by systemd, but this is basically just a guess at this point. I found it interesting that setting the x bit on the directory and even 777 file permission didn't work, which is what lead me to the ACL's.

TIL: Worth noting that ACL's can override file permissions. Whichever has the most restrictive setting gets precedence.

An system that worked out of the box. Note the r-x group permissions.

$ getfacl "${HOME}"
getfacl: Removing leading '/' from absolute path names
# file: home/jeff
# owner: jeff
# group: alpm
user::rwx
group::r-x
other::---

A system with the error. The group permission appears not set, even though the file permission on the directory had read permission for alpm.

$ getfacl "${HOME}"
getfacl: Removing leading '/' from absolute path names
# file: home/jeff
# owner: jeff
# group: alpm
user::rwx
user:libvirt-qemu:--x
group::---
mask::r-x
other::---

To set the group alpm permissions, I ran:

$ setfacl -m g:alpm:r-x "${HOME}"

And now rechecking the settings:

$ getfacl "${HOME}"
getfacl: Removing leading '/' from absolute path names
# file: home/jeff
# owner: jeff
# group: alpm
user::rwx
user:libvirt-qemu:--x
group::---
group:alpm:r-x
mask::r-x
other::---

Additional info:
https://bbs.archlinux.org/viewtopic.php?id=299556
https://www.reddit.com/r/systemd/commen … container/

Last edited by NuSkool (2024-10-03 22:33:11)

Arch Linux

#1 2024-09-17 06:05:12

Pacman 7.0 DownloadUser, Sandbox, with a local AUR repo

#2 2024-09-17 06:46:34

Re: Pacman 7.0 DownloadUser, Sandbox, with a local AUR repo

#3 2024-09-17 18:49:35

Re: Pacman 7.0 DownloadUser, Sandbox, with a local AUR repo

Board footer