`podman run` fails when HOME set to invalid path and unprivileged system user specified as systemd `User=`

[Valloric]

Issue Description

podman run fails to run a rootless service when XDG_CONFIG_HOME is unset and an unprivileged, system user that has HOME set to an invalid path is used as User=.

At a guess, this appears to be caused due to the following behavior, described in podman docs:

In Rootless mode configuration files are read from XDG_CONFIG_HOME when specified, otherwise in the home directory of the user under $HOME/.config/containers

podman run fails to account for a missing $HOME dir. Lack of additional config files should not cause podman to fail. Default settings should... default.

Adding Environment=XDG_CONFIG_HOME=/run/user/$TEST_UID or Environment=HOME=/run/user/$TEST_UID to [Service] works around the bug. Note: these workarounds are effective even if the provided folders are empty, thus it is not the case that "Rootless mode configuration files" must be provided.

Why is HOME set to an invalid path?

Because that's what Debian policy requires:

The canonical non-existent home directory is /nonexistent. Users who should not have a home directory should have their home directory set to this value.

System users should not have a home directory for security reasons.

Steps to reproduce the issue

# Create the unprivileged system user
useradd \
  --system \
  --add-subids-for-system \
  --shell /usr/sbin/nologin \
  --user-group \
  --no-create-home \
  --home-dir /nonexistent \
  --key UMASK=077 \
  test-user

# Capture the UID 
TEST_UID=$(id -u test-user)

# Write the service file
cat << EOF > /etc/systemd/system/test-service.service
[Unit]
Description=Podman test service

[Service]
User=test-user
Environment=XDG_DATA_HOME=/run/user/$TEST_UID
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
KillMode=mixed
Delegate=yes
Type=notify
NotifyAccess=all
SyslogIdentifier=%N

ExecStop=/usr/bin/podman rm -v -f -i --cidfile=/run/user/$TEST_UID/%N.cid
ExecStopPost=-/usr/bin/podman rm -v -f -i --cidfile=/run/user/$TEST_UID/%N.cid
ExecStart=/usr/bin/podman run \
  --name myservice \
  --cidfile=/run/user/$TEST_UID/%N.cid \
  --replace \
  --rm \
  --cgroups=split \
  --sdnotify=conmon \
  --detach \
  docker.io/bash:5.3.0 \
  -c 'exec tail -f /dev/null'

[Install]
WantedBy=multi-user.target
EOF

# Reload systemd and start the service (it will fail)
systemctl daemon-reload && systemctl start test-service.service

# See errors in log
journalctl --boot --pager-end --unit test-service

Describe the results you received

Jul 21 07:20:20 prime systemd[1]: test-service.service: Scheduled restart job, restart counter is at 3.
Jul 21 07:20:20 prime systemd[1]: Starting test-service.service...
Jul 21 07:20:20 prime test-service[686581]: cannot resolve /nonexistent: lstat /nonexistent: no such file or directory
Jul 21 07:20:20 prime systemd[1]: test-service.service: Main process exited, code=exited, status=1/FAILURE
Jul 21 07:20:20 prime test-service[686590]: cannot resolve /nonexistent: lstat /nonexistent: no such file or directory
Jul 21 07:20:20 prime systemd[1]: test-service.service: Failed with result 'exit-code'.
Jul 21 07:20:20 prime systemd[1]: Failed to start test-service.service.

Describe the results you expected

podman run succeeds without errors

podman info output

host:
  arch: amd64
  buildahVersion: 1.39.3
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.12-4_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: unknown'
  cpuUtilization:
    idlePercent: 98.55
    systemPercent: 0.21
    userPercent: 1.24
  cpus: 4
  databaseBackend: sqlite
  distribution:
    codename: trixie
    distribution: debian
    version: "13"
  eventLogger: journald
  freeLocks: 2048
  hostname: prime
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.12.35+deb13-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 9958391808
  memTotal: 16540606464
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns_1.14.0-3_amd64
      path: /usr/lib/podman/aardvark-dns
      version: aardvark-dns 1.14.0
    package: netavark_1.14.0-2_amd64
    path: /usr/lib/podman/netavark
    version: netavark 1.14.0
  ociRuntime:
    name: crun
    package: crun_1.21-1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.21
      commit: 10269840aa07fb7e6b7e1acff6198692d8ff5c88
      rundir: /run/user/0/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt_0.0~git20250503.587980c-2_amd64
    version: ""
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: true
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.1-1.1_amd64
    version: |-
      slirp4netns version 1.2.1
      commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.6.0
  swapFree: 16540602368
  swapTotal: 16540602368
  uptime: 208h 10m 13.00s (Approximately 8.67 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 491463127040
  graphRootUsed: 6145794048
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 0
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.4.2
  BuildOrigin: Debian
  Built: 1751958912
  BuiltTime: Tue Jul  8 09:15:12 2025
  GitCommit: ""
  GoVersion: go1.24.4
  Os: linux
  OsArch: linux/amd64
  Version: 5.4.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

$ uname -a
Linux prime 6.12.35+deb13-amd64 containers/image#1 SMP PREEMPT_DYNAMIC Debian 6.12.35-1 (2025-07-03) x86_64 GNU/Linux

$ lsb_release -a
Distributor ID: Debian
Description:    Debian GNU/Linux 13 (trixie)
Release:        13
Codename:       trixie

$ podman --version
podman version 5.4.2

$ systemctl --version
systemd 257 (257.7-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE

Additional information

(none)

[Luap99]

[Service]
User=test-user

We generally don't support that because it doesn't actually create a proper user session which causes a lot of other problems, no proper cgroup management for example. There is more discussion in #20573 but it is not something.

Without proper XDG_RUNTIME_DIR set we default to /tmp which is not optimal and without HOME I am not sure how you would even expect podman to write any of its images since we default to writing in $HOME/.local/share/...?

There are some cases where we do indeed should not read the config files and don't error on this, i.e. #23818 but I am not sure the regular podman should be expected to work without a proper HOME defined.
But yes see my comments there in general I agree that reading config files should never fail with ENOENT and instead we should ignore it instead.

[Valloric]

Without proper XDG_RUNTIME_DIR set

I can manually create sessions and set XDG_RUNTIME_DIR just fine. This is not what this bug report is about.

This issue report is about Podman demanding HOME be set to a valid path because it's read as a fallback for XDG_CONFIG_HOME, which doesn't make sense because an empty folder works just fine.

Either fail on valid-but-empty HOME or stop failing on invalid HOME. I don't see a case for the current behavior.

There is more discussion in #20573 but it is not something.

I have read through that entire discussion and all linked bugs and PRs before filing this issue. In fact, I'm in the process of trying to find a good set of workarounds for using a system user for running rootless containers.

I can already make it work; I'm trying to file bugs for the workarounds that should not be necessary (like this bug).

without HOME I am not sure how you would even expect Podman to write any of its images since we default to writing in $HOME/.local/share/...?

Podman documentation says:

In Rootless mode images are pulled under XDG_DATA_HOME when specified, otherwise in the home directory of the user under $HOME/.local/share/containers/storage.

I can set XDG_DATA_HOME to whatever directory works for me. HOME is not necessary (or desired, because of security).

but I am not sure the regular Podman should be expected to work without a proper HOME defined.

Why?

[Luap99]

Either fail on valid-but-empty HOME or stop failing on invalid HOME. I don't see a case for the current behavior.

Which is what I said in #23818 so I close this as dup then

HOME is not necessary (or desired, because of security).

How is not having a valid $HOME any more secure than having it? If you still set all the XDG_ dirs then you still have many user writeable directories so I fail to see how this can be a security argument at all. The debina link you gave doesn't mention security either.

[Valloric]

@Luap99

How is not having a valid $HOME any more secure than having it?

One fewer directory to secure?

If you still set all the XDG_ dirs then you still have many user writeable directories so I fail to see how this can be a security argument at all. The debina link you gave doesn't mention security either.

The main argument isn't so much "security", it's "all the tools for creating system users do not create a home directory for them" and Podman (IMO, needlessly) adds another stumbling block to using system users.

adduser --system docs:

If no home directory is specified, the default home directory for a new system user is /nonexistent. This directory should never exist on any Debian system, and adduser will never create it automatically.

useradd --system docs

Note that useradd will not create a home directory for such a user, regardless of the default setting in /etc/login.defs (CREATE_HOME). You have to specify the -m options if you want a home directory for a system account to be created.

Ansible's ansible.builtin.user module also uses useradd under the hood, so setting system: true will not create the home directory.

All the tools that I (and many, many others) regularly use to create system users will intentionally not create a valid HOME directory for them.

I don't understand why I'm being asked to defend the idea that "system users don't have valid HOME directories", it predates us both likely by decades. :)

[Luap99]

It is not about defending I just don't buy the argument that this matters for security in any way as long as you still have to expose writeable directories for the user.

In any case like I said I agree this specific instance is a valid but it is already tracked in the other issue so there is no point in having dups here.
If there other $HOME access issues feel free to report them but I am not sure if all of them can be fixed. For example there are still many config files that only lookup in $HOME so you won't able to configure them then if you don't have $HOME/ containers/container-libs#183 Sure again stuff that should be fixed eventually but it won't work for the moment.
Also looking at more code paths I see we at least create $HOME/.ssh/known_hosts for example when doing ssh connections. I am not aware of having a XDG_ directory preference for that one?

Podman needing a full user session for most of it things is in general already in full contrast to what a normal system user is so by the point where you again expose a full systemd user session for this "system" user it seems to be basically a normal user with $HOME? And that does not seem particular more useful or secure to me. But anyway no much point in arguing about such things.