Description
Running the salt-master process under the salt user breaks pam eauth as the salt user can't read /etc/shadow and /etc/gshadow

This issue is documented in SEP19 and Issue 7762

Setup

• Salt 3006.x installed from Debian packages
• Same issue will exist with RPM packages but I haven't specifically tested

Steps to Reproduce the behavior

Configure the salt master to use pam eauth -

$ cat /etc/salt/master.d/ext_auth.conf

external_auth:
  pam:
    testuser:
      - '.*'

$  sudo salt -a pam --username=testuser \* test.ping
password: <password>
Authentication error occurred.

Expected behavior

$ sudo salt -a pam --username=testuser \* test.ping
password: <password>
testhost:
    True

Versions Report

$ salt --versions-report
Salt Version:
          Salt: 3006.1

Python Version:
        Python: 3.10.11 (main, May  5 2023, 02:31:54) [GCC 11.2.0]

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.2
       libgit2: Not Installed
  looseversion: 1.0.2
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 22.0
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: Not Installed
  python-gnupg: 0.4.8
        PyYAML: 5.4.1
         PyZMQ: 23.2.0
        relenv: 0.12.3
         smmap: Not Installed
       timelib: 0.2.4
       Tornado: 4.5.
           ZMQ: 4.3.4

System Versions:
          dist: ubuntu 20.04.6 focal
        locale: utf-8
       machine: x86_64
       release: 5.4.0-148-generic
        system: Linux
       version: Ubuntu 20.04.6 focal

Additional context

This was a known issue with running with the salt-master as a non-root user - documented in SEP19, issue 61770 and has been called out in the eauth documentation for a long time...

There's a simple fix for Debian derived distributions - adding the salt user to the shadow group allows the salt-master process to read /etc/shadow and resolves
the issue. This doesn't work for RH derived distros.

I'd suggest that for Debian derivatives whether to add salt to the shadow group should be asked through debconf - that way folk that need to use eauth/pam can do so but those who don't, don't expose the content of /etc/shadow to the salt user.

I'm not sure how to easily handle this to RPM packages as I'm less familiar with the options there.

Best long term solution would be to have a small separate privileged process for pam eauth that the salt master queries for authentication.