[BUG] saltutil.runner/wheel as the master user fails git_pillar/gitfs: failed to stat '/root/.gitconfig'

[ggiesen]

Description

After #69240 (fix for #67716), saltutil.runner and saltutil.wheel correctly drop to the master's configured user (salt) before running master-side functions. But the privilege drop uses salt.utils.user.chugid(), which changes only the uid/gid and leaves HOME/USER/LOGNAME pointing at the invoking (minion) user, typically root.

Git-backed master functions then read the wrong user's git configuration. With the pygit2/libgit2 provider (the onedir default), opening the cache repo stats $HOME/.gitconfig = /root/.gitconfig, which the unprivileged salt user cannot access:

_pygit2.GitError: /var/cache/salt/master/git_pillar/<id>/_: failed to stat '/root/.gitconfig'
...
salt.exceptions.FileserverConfigError: Failed to load git_pillar

The same applies to the GitPython and (3008+) gitcli providers, which also consult $HOME via the git binary. salt.utils.verify.check_user already sets HOME/USER/LOGNAME from the target user when the daemon drops privileges; the saltutil runas path does not.

Setup

• onedir packaging; master runs as the salt user (3006 default), minion runs as root.

Steps to Reproduce the behavior

On a master+minion where the master user is salt and the minion runs as root, with git_pillar configured:

salt <minion> saltutil.runner git_pillar.update

Expected behavior

The runner runs as the salt user with that user's environment, so git_pillar.update succeeds instead of failing on /root/.gitconfig.

Versions Report

3006.26. Regression introduced by #69240; present wherever that fix is merged forward.

[ggiesen]

Until #69570 merges and ships (expected 3006.27), here is a Salt state to apply just that saltutil.py change on an affected 3006.26 master. file.patch dry-runs first and refuses to apply if your saltutil.py does not match, so it will not silently change anything on a different version.

1. Save the saltutil.py change from #69570 where your minion can reach it (e.g. salt://files/saltutil_69569.patch, or a local absolute path):

diff -urN a/salt/modules/saltutil.py b/salt/modules/saltutil.py
--- a/salt/modules/saltutil.py
+++ b/salt/modules/saltutil.py
@@ -17,6 +17,11 @@
 import time
 import urllib.error
 
+try:
+    import pwd
+except ImportError:
+    pwd = None
+
 import salt
 import salt.channel.client
 import salt.client
@@ -1779,6 +1784,50 @@
     return runas
 
 
+def _align_runas_environment(runas):
+    """
+    Align the process environment with ``runas`` after dropping privileges.
+
+    ``salt.utils.user.chugid`` changes the uid/gid but leaves ``HOME``,
+    ``USER`` and ``LOGNAME`` pointing at the invoking user (typically
+    ``root``). Tools that consult ``$HOME`` -- notably git, GitPython and
+    pygit2/libgit2 behind gitfs and git_pillar -- would then read the wrong
+    user's configuration and fail (e.g. ``failed to stat '/root/.gitconfig'``
+    when running as the unprivileged master user). Mirror what
+    :func:`salt.utils.verify.check_user` does for the master daemon. See
+    #67716.
+    """
+    if pwd is None:
+        return
+    try:
+        pwuser = pwd.getpwnam(runas)
+    except KeyError:
+        return
+    os.environ["HOME"] = pwuser.pw_dir
+    os.environ["USER"] = pwuser.pw_name
+    os.environ["LOGNAME"] = pwuser.pw_name
+    # libgit2 caches its global-config search path from $HOME the first time
+    # pygit2 is imported. If pygit2 was already imported before privileges
+    # were dropped, that cache still points at the invoking user's home, so
+    # refresh it to the runas user's home as well.
+    pygit2 = sys.modules.get("pygit2")
+    if pygit2 is not None:
+        try:
+            config_level = getattr(getattr(pygit2, "enums", None), "ConfigLevel", None)
+            global_level = (
+                config_level.GLOBAL
+                if config_level is not None
+                else pygit2.GIT_CONFIG_LEVEL_GLOBAL
+            )
+            pygit2.settings.search_path[global_level] = pwuser.pw_dir
+        except Exception:  # pylint: disable=broad-except
+            log.debug(
+                "Could not refresh pygit2 global config search path for user %s",
+                runas,
+                exc_info=True,
+            )
+
+
 def _client_cmd_as(runas, client, name, cmd_kwargs):
     """
     Run ``client.cmd(name, **cmd_kwargs)`` in a child process that has dropped
@@ -1794,6 +1843,7 @@
     def _run():
         try:
             salt.utils.user.chugid(runas)
+            _align_runas_environment(runas)
             queue.put(("ret", client.cmd(name, **cmd_kwargs)))
         except Exception as exc:  # pylint: disable=broad-except
             queue.put(("err", f"{exc.__class__.__name__}: {exc}"))

2. Apply it (adjust the source to wherever you saved the patch):

saltutil_69569_fix:
  file.patch:
    - name: /opt/saltstack/salt/lib/python3.10/site-packages/salt/
    - source: salt://files/saltutil_69569.patch   # or a local absolute path
    - strip: 2

3. Restart the minion that runs your orchestration/runner so it reloads the patched module:

systemctl restart salt-minion

Reproduced and verified on a 3006.26 onedir master (pygit2 1.11.1 / libgit2 1.5.0): salt <minion> saltutil.runner git_pillar.update fails with _pygit2.GitError: failed to stat '/root/.gitconfig' -> FileserverConfigError: Failed to load git_pillar before the patch, and succeeds after.