quadlet: handle missing HOME in rootless configuration lookup

[shrevid03]

Summary

This addresses #29284, where rootless Quadlet files can be discovered by
podman quadlet list but are not loaded by the systemd user generator in the
reproduced systemd-homed setup.

I reproduced the issue on Fedora CoreOS 44 using a disposable user created with
homectl. The actual user-generator environment was:

HOME=/
XDG_CONFIG_HOME=
XDG_RUNTIME_DIR=/run/user/60104

Rootless Quadlet uses os.UserConfigDir() to determine the user's configuration
directory. With HOME=/ and no XDG_CONFIG_HOME, this resolves to /.config,
so the user's actual ~/.config/containers/systemd directory is not searched.

User lookup still returns the correct home directory:

quadtest:x:60104:60104:quadtest:/home/quadtest:/bin/bash

The change reuses Podman's existing GetRootlessConfigHomeDir() path when the
rootless home environment is unusable. For the reproduced HOME=/ case, the
helper resolves the rootless user's UID using rootless.GetRootlessUID() and
uses the home directory returned by the user database.

Normal Quadlet lookup continues to use os.UserConfigDir(), and explicit
XDG_CONFIG_HOME behavior remains unchanged.

Fixes: #29284

Reproduction

I created a disposable systemd-homed user and placed pgsql.container and
pgsql.pod under:

/var/home/quadtest/.config/containers/systemd/

Before the fix:

• podman quadlet list discovered both files but reported them as Not loaded.
• /usr/libexec/podman/quadlet -dryrun -user from the user's normal login environment generated both units correctly.
• systemctl --user daemon-reload generated neither unit.

The actual environment observed for podman-user-generator was:

uid=60104
user=quadtest
home=/
xdg_config_home=
xdg_runtime_dir=/run/user/60104

Running Quadlet manually with the same HOME=/ environment reproduced the
discovery failure, narrowing the issue to rootless config-directory resolution
in the generator environment.

Testing

Added TestGetRootlessConfigHomeDirWithRootHome in the Linux util tests to
cover the HOME=/ regression.

The relevant package tests pass:

$ go test ./pkg/util ./pkg/systemd/quadlet -count=1
ok      go.podman.io/podman/v6/pkg/util
ok      go.podman.io/podman/v6/pkg/systemd/quadlet

git diff --check also passes.

During the original reproduction, I also built the patched Quadlet binary and
exercised the systemd user-generator path. After:

systemctl --user daemon-reload

the previously missing units were generated:

/run/user/60104/systemd/generator/pgsql.service
/run/user/60104/systemd/generator/pgsql-pod.service

make validatepr was also attempted, but golangci-lint was killed with exit
137 on the 2 GB validation VM, so the full validation did not complete.

Scope

The change is limited to rootless Quadlet source-directory lookup when the
systemd user generator does not receive a usable home directory.

It does not change:

• normal HOME handling
• explicit XDG_CONFIG_HOME handling
• rootful Quadlet discovery
• podman quadlet install

[mheon]

We already have a function that does this - pkg/util/utils_supported.go has GetRootlessConfigHomeDir() - I would expect us to re-use that, possibly with modifications.

[mheon]

Is this homectl behavior documented anywhere? The completely-unset XDG_CONFIG_HOME and garbage setting for HOME seem like they are a complete contravention of Linux norms and would break so many things, to the point where I have to wonder if they are deliberate or not.

[shrevid03]

Thanks @mheon for pointing that out. I missed GetRootlessConfigHomeDir() when I first worked on this. I’ve updated the patch to remove the Quadlet-specific helper and reuse the existing util helper instead. I also moved the regression test into pkg/util/utils_linux_test.go.
I reran the util and Quadlet package tests after the change, and they both passed.

[shrevid03]

@mheon I looked through the systemd docs, but I couldn’t find anything saying that HOME=/ is expected behavior for a systemd-homed user.
What I did confirm during the reproduction is that the actual podman-user-generator process was getting HOME=/ with XDG_CONFIG_HOME unset, while the user lookup for the same UID still returned /home/quadtest. Running Quadlet manually with that same environment also reproduced the failure.
I did enable linger for the test user while setting up the reproduction, so that’s one thing I haven’t ruled out yet. For now I’m treating HOME=/ as what triggered the issue in this setup rather than assuming it’s normal homectl behavior. I can rerun it without linger as well if that would help narrow down where the environment is coming from.

[Luap99]

Is this homectl behavior documented anywhere? The completely-unset XDG_CONFIG_HOME and garbage setting for HOME seem like they are a complete contravention of Linux norms and would break so many things, to the point where I have to wonder if they are deliberate or not.

I agree input garbage == output garbage, its not our task to special case incorrect settings. This will create a total mess in the codebase when we just start ignoring certain things in certain places. If the systemd generator env sets these envs incorrectly then it needs to be fixed there IMO.

[ygalblum]

I commented about the code in case it still gets approved.
But, I agree with @Luap99 this seems like an environment issue caused by systemd. If we bypass it here, what guaranties that we don't hit the next issue caused by this incomplete environment?

[ygalblum]

Why can't Quadlet just call util.GetRootlessConfigHomeDir with the new addition? All these checks seem duplicated