Arch Linux install script does not appear to preserve xattrs when moving new installation files to disk

[lithiumsulfate]

I came upon an odd problem where on a new installation of Arch Linux using the Hetzner installimage, I was unable to setup podman because the /usr/bin/newuidmap binary from the shadow package was missing the required capabilities (cap_setuid=ep). This was particularly odd as this is the standard configuration shipped by the shadow package upstream, the capabilities are in fact present on every other system I run and I do not remember manually fiddling with them on the affected system.

I believe I was able to trace this problem back to a potential issue with the install script for Arch Linux. As far as I understand the script, it first uses pacstrap to set up the new system into /mnt (canonical for the installation of Arch), then it moves all files into the actual mount point for the disk, using rsync -a:

installimage/archlinux.sh

Lines 59 to 68 in e15b5ea

	# pacstrap
	local newroot='/mnt'
	debug "# archlinux-bootstrap: run $arch_chroot_script $chroot_dir pacstrap -G -M $newroot $archlinux_packages"
	"$arch_chroot_script" "$chroot_dir" pacstrap -G -M "$newroot" $archlinux_packages |& debugoutput || return 1
	# move newroot
	debug '# move /mnt to /'
	umount "$chroot_dir" |& debugoutput || return 1
	debug "# run rsync -a --remove-source-files $chroot_dir/$newroot/ $hdd_dir/"
	rsync -a --remove-source-files "$chroot_dir/$newroot/" "$hdd_dir/" |& debugoutput || return 1

However rsync does not preserve the extended attributes of files (where the capabilities are stored) by default unless also specifying -X, causing them (and thus the capabilities) to be dropped in the finalized setup, which can eventually lead to odd issues like what I found with podman.

I do not have the means currently to confirm this behavior with the install script itself, but I did a quick test with rsync on my local system to confirm that the xattrs are being dropped when omitting -X:

# rsync -a /usr/bin/newuidmap ./newuidmap
# getcap ./newuidmap 
(no output)
# getfattr -d -m - ./newuidmap
(no output)


# rsync -aX /usr/bin/newuidmap ./newuidmap
# getcap ./newuidmap 
./newuidmap cap_setuid=ep
# getfattr -d -m - ./newuidmap
# file: newuidmap
security.capability=0sAQAAAoAAAAAAAAAAAAAAAAAAAAA=

This was easily remedied by reinstalling the affected package (shadow) on the live system and thus would have gone by entirely unnoticed if this happened as part of a regular system update before I tried to use any applications relying on the xattrs (as was the case on my previous installation using installimage). However, there might be more packages updated even less frequently than shadow with xattrs shipped by default which might be affected by this bug as well.