Podman compatibility with root-owned configuration directories in restricted environments

[olvasyle]

Hello,

Podman version: 5.6.0
OS: RHEL 9.7
Kernel: 5.14.0-611.30.1.el9_7.x86_64

We have some questions and suggestions regarding the XDG_CONFIG_HOME variable and the ownership requirements for the .config directory:

container-libs/storage/pkg/homedir/homedir_unix.go

Lines 107 to 134 in 8af7873

	func GetConfigHome() (string, error) {
	rootlessConfigHomeDirOnce.Do(func() {
	cfgHomeDir := os.Getenv("XDG_CONFIG_HOME")
	if cfgHomeDir == "" {
	home := Get()
	resolvedHome, err := filepath.EvalSymlinks(home)
	if err != nil {
	rootlessConfigHomeDirError = fmt.Errorf("cannot resolve %s: %w", home, err)
	return
	}
	tmpDir := filepath.Join(resolvedHome, ".config")
	_ = os.MkdirAll(tmpDir, 0o700)
	st, err := os.Stat(tmpDir)
	if err != nil {
	rootlessConfigHomeDirError = err
	return
	} else if int(st.Sys().(*syscall.Stat_t).Uid) == os.Geteuid() {
	cfgHomeDir = tmpDir
	} else {
	rootlessConfigHomeDirError = fmt.Errorf("path %q exists and it is not owned by the current user", tmpDir)
	return
	}
	}
	rootlessConfigHomeDir = cfgHomeDir
	})
	return rootlessConfigHomeDir, rootlessConfigHomeDirError
	}

Currently, Podman requires that the user executing a command must be the owner of ~/.config. In our CI/CD environment, the .config directory is owned by root as a security measure to prevent build processes from modifying configuration files, except for specific, authorized exceptions. Granting ownership of this directory to the CI/CD user would broaden our attack surface by providing excessive permissions to the users managing and running these builds. Consequently, adhering to the current Podman requirement actually reduces the security of our setup.

Additionally, the CI/CD user's home directory is also owned by root. From a Podman perspective, we are curious why the .config directory requires user ownership while the parent home directory does not.

To address this, we would like to propose the following:

1. Would it be possible to allow Podman to function on Unix systems if the .config directory is owned by either the user executing the command or by root?
2. Alternatively, could Podman be updated to only require ownership of the specific subdirectories it utilizes (such as containers and cni), rather than the entire ~/.config directory? This would allow us to maintain root ownership of the parent directory while granting the user access to the specific paths required for Podman to function.
3. Relying on XDG_CONFIG_HOME can sometimes have unintended side effects for other applications in a shared environment. Introducing a specific variable (e.g., PODMAN_CONFIG_HOME) would allow for more granular control without impacting the rest of the system's configuration environment.

We would appreciate your perspective on whether these approaches are feasible or if there is a recommended best practice for this scenario. Thank you for your time and your work on Podman.

[mtrmac]

Thanks for reaching out!

This exists primarily to prevent unprivileged users doing su root (or something similar which inherits $XDG_CONFIG_HOME) and having the root-owned process overwrite their .config.

That’s still a relevant concern, but perhaps not for accesses that only read that configuration. @Luap99 is working in this space, and IIRC there are changes in progress.

[Luap99]

The current new config file READING code path will not call this code to avoid checking permission to fix problems like that.
So in that sense yes this will be fixed there but that is only on the READING side of containers.conf, registries.conf, storage.conf, etc...

In practise the concern of overwriting something still exists so code paths that WRITE something there would certainly want to make sure they own that directory? So I think while my changes remove a fair amount of calls on it we still seem to have some callers that get always invoked in podman so this problem will no go away.

There is definitely some investigation work necessary of the pros and cons and history of why these checks were added to make a good call.

--

In general if you are using RHEL and have active RHEL support you likely should report this through support to our internal trackers for better prioritization if you want to have better chances of this getting worked on.