unshare --map-auto --map-current-user --setuid 0 --setgid 0 fails

[akihikodaki]

mkosi commit the issue has been seen with

main

Used host distribution

Fedora 43

Used target distribution

Fedora Rawhide

Linux kernel version used

6.18.10+

CPU architectures issue was seen on

aarch64

Unexpected behaviour you saw

The man page says:

mkosi/mkosi/resources/man/mkosi.1.md

Lines 3418 to 3425 in 1e439b6

	If this behavior causes applications running in your image to misbehave, you
	can consider running **mkosi** as root which avoids this problem. Alternatively,
	if running **mkosi** as root is not desired, you can use
	`unshare --map-auto --map-current-user --setuid 0 --setgid 0` to become root in
	a user namespace with more than one user assuming the UID/GID mappings in
	`/etc/subuid` and `/etc/subgid` are configured correctly. Note that running mkosi
	as root or with `unshare` means that all output files produced by **mkosi** will not
	be owned by your current user anymore.

However, the following command fails:

unshare --map-auto --map-current-user --setuid 0 --setgid 0 pipx run --spec git+https://github.com/systemd/mkosi.git mkosi --debug

Used mkosi config

# SPDX-License-Identifier: LGPL-2.1-or-later
[Include]
Include=mkosi-vm

[Build]
CacheDirectory=mkosi.cache
History=yes

[Output]
# These images are (among other things) used for running mkosi which means we need some disk space available so
# default to directory output where disk space isn't a problem.
Format=directory
OutputDirectory=mkosi.output

[Build]
ToolsTree=yes
Incremental=yes
BuildSources=.

[Content]
Autologin=yes
SELinuxRelabel=no
ShimBootloader=unsigned

Packages=
        binutils
        gdb
        wireless-regdb

InitrdProfiles=lvm

RemoveFiles=
        # The grub install plugin doesn't play nice with booting from virtiofs.
        /usr/lib/kernel/install.d/20-grub.install
        # The dracut install plugin doesn't honor KERNEL_INSTALL_INITRD_GENERATOR.
        /usr/lib/kernel/install.d/50-dracut.install

# Make sure that SELinux doesn't run in enforcing mode even if it's pulled in as a dependency.
KernelCommandLine=
        enforcing=0
        systemd.log_ratelimit_kmsg=0
        systemd.crash_shell
        printk.devkmsg=on
        systemd.early_core_pattern=/core

KernelInitrdModules=default

[Runtime]
RAM=4G

mkosi output

mkosi is already on your PATH and installed at /usr/bin/mkosi. Downloading and running anyway.
‣ Loading configuration file /home/me/mkosi/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf.d/azure-centos-fedora/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/networkd.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/uefi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf.d/azure-centos-fedora/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/networkd.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-vm/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/uefi.conf
‣ Loading configuration file /home/me/mkosi/mkosi.conf.d/azure-centos-fedora/mkosi.conf
‣ Loading configuration file /home/me/mkosi/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/arm64.conf
‣ Loading configuration file /home/me/mkosi/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/uefi.conf
‣ Loading configuration file /home/me/mkosi/mkosi.conf.d/bootable.conf
‣ Loading configuration file /home/me/mkosi/mkosi.conf.d/fedora/mkosi.conf
‣ Loading configuration file /home/me/mkosi/mkosi.conf.d/fedora/mkosi.conf.d/arm64.conf
‣ Loading configuration file /home/me/mkosi/mkosi.tools.conf/mkosi.conf
‣ Loading configuration file /home/me/mkosi/mkosi.tools.conf/mkosi.conf.d/azure-centos-fedora.conf
‣ Loading configuration file /home/me/mkosi/mkosi.tools.conf/mkosi.conf.d/fedora.conf
‣ Loading configuration file /home/me/mkosi/mkosi.tools.conf/mkosi.conf.d/ncdu.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.conf.d/azure-centos-fedora/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/efi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.conf.d/azure-fedora/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.conf.d/fedora/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/misc/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/misc/mkosi.conf.d/azure-centos-fedora.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/package-manager/mkosi.conf.d/fedora.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/runtime/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/runtime/mkosi.conf.d/azure-centos-fedora/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/runtime/mkosi.conf.d/azure-centos-fedora/mkosi.conf.d/edk2-ovmf.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-tools/mkosi.profiles/runtime/mkosi.conf.d/fedora.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-initrd/mkosi.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-initrd/mkosi.conf.d/arm.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-initrd/mkosi.conf.d/azure-centos-fedora.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-initrd/mkosi.conf.d/fedora.conf
‣ Loading configuration file /tmp/tmpbirwo7nk/resources/mkosi-initrd/mkosi.profiles/lvm/mkosi.conf
‣ Could not provision user namespace via systemd-nsresourced ([Errno 2] No such file or directory), falling back to unprivileged user namespace via unshare(CLONE_NEWUSER) and writing /proc/self/uid_map directly
‣ /home/me/mkosi/mkosi.tools does not exist, not reusing cached images
‣ /home/me/mkosi/mkosi.tools does not exist, not reusing cached images
‣ + tput cnorm
‣ + tput smam
Traceback (most recent call last):
  File "/usr/lib64/python3.14/pathlib/__init__.py", line 1011, in mkdir
    os.mkdir(self, mode)
    ~~~~~~~~^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/var/cache/mkosi/fedora~rawhide~arm64'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/me/.cache/pipx/ec9e71cbb07084a/lib64/python3.14/site-packages/mkosi/run.py", line 104, in uncaught_exception_handler
    yield
  File "/usr/lib64/python3.14/contextlib.py", line 85, in inner
    return func(*args, **kwds)
  File "/home/me/.cache/pipx/ec9e71cbb07084a/lib64/python3.14/site-packages/mkosi/__main__.py", line 44, in main
    run_verb(args, tools, images, resources=resources)
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/me/.cache/pipx/ec9e71cbb07084a/lib64/python3.14/site-packages/mkosi/__init__.py", line 5038, in run_verb
    ensure_directories_exist(tools)
    ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "/home/me/.cache/pipx/ec9e71cbb07084a/lib64/python3.14/site-packages/mkosi/__init__.py", line 4787, in ensure_directories_exist
    p.mkdir(parents=True, exist_ok=True)
    ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/pathlib/__init__.py", line 1015, in mkdir
    self.parent.mkdir(parents=True, exist_ok=True)
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/pathlib/__init__.py", line 1011, in mkdir
    os.mkdir(self, mode)
    ~~~~~~~~^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: '/var/cache/mkosi'

[behrmann]

That's fallout from changes how we determine the cache directory. You can either set XDG_CACHE_DIRECTORY or CACHE_DIRECTORY. The fallback of /var/cache is not writable by regular users (for good reason) and is there for when mkosi is invoked by the root user.

[akihikodaki]

Eventually I settled on:

XDG_CACHE_HOME="$HOME/.cache" unshare --map-user 0 --map-group 0 \
    --map-users "1:$(($(awk -F: -v u="$USER" '$1==u {print $2; exit}' /etc/subuid) + 1)):65535" \
    --map-groups "1:$(($(awk -F: -v u="$USER" '$1==u {print $2; exit}' /etc/subgid) + 1)):65535"

This gives a mapping identical to virtiofsd invoked by mkosi vm.

[JiwaniZakir]

The combination of --map-auto and --map-current-user requires both /etc/subuid and /etc/subgid to have valid subordinate ID ranges configured for the current user, since --map-auto invokes newuidmap/newgidmap to set up the combined mapping. On Fedora 43, it's also worth checking whether kernel.apparmor_restrict_unprivileged_userns (or the equivalent user.max_user_namespaces sysctl) is restricting unprivileged namespace creation — Fedora has been progressively tightening these defaults. The truncated mkosi output suggests it may be failing during the early namespace setup phase rather than inside the build itself, which would point toward the unshare invocation in mkosi/sandbox.py (or wherever the user namespace is bootstrapped) rather than a config parsing issue. Confirming whether unshare --map-auto --map-current-user --setuid 0 --setgid 0 /bin/bash alone reproduces the failure (outside of mkosi) would help isolate whether this is a host environment issue or something specific to how mkosi invokes unshare.

[akihikodaki]

I don't think that's what this trace is showing.

The general point about --map-auto/--map-current-user needing valid subordinate ID ranges may be true in principle, but it doesn't look like the failing piece here: the command clearly gets far enough to start mkosi, load config, and then log that it is "falling back to unprivileged user namespace via unshare(CLONE_NEWUSER)". If namespace creation itself were being blocked, I'd expect failure in that path, not a later PermissionError while creating /var/cache/mkosi/....

Likewise, I don't think the Fedora/AppArmor suggestion fits this report. kernel.apparmor_restrict_unprivileged_userns is the Ubuntu/AppArmor knob; and if user.max_user_namespaces were the problem, again, I would expect the unshare step itself to fail.

What seems more likely is that unshare --map-auto --map-current-user --setuid 0 --setgid 0 makes mkosi run as uid 0 inside the user namespace. In that case mkosi's cache-dir lookup falls back to /var/cache unless XDG_CACHE_HOME or CACHE_DIRECTORY is set. Root in a user namespace still cannot write the host's /var/cache, so the failure ends up being:
PermissionError: [Errno 13] Permission denied: '/var/cache/mkosi'

So I think this issue is about cache-directory selection when mkosi is invoked as "root in a user namespace", not an early failure in mkosi/sandbox.py or namespace setup. That also matches the earlier workaround of setting XDG_CACHE_HOME="$HOME/.cache".