Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dmidecode permission error on master with non-root salt-master #66152

Open
2 tasks done
jg-basis opened this issue Feb 28, 2024 · 2 comments
Open
2 tasks done

dmidecode permission error on master with non-root salt-master #66152

jg-basis opened this issue Feb 28, 2024 · 2 comments
Labels
Bug broken, incorrect, or confusing behavior needs-triage

Comments

@jg-basis
Copy link

Description
Error logged in salt master log related to permissions

[salt.loader.lazy :977 ][DEBUG   ][3765414] The functions from module 'core' are being loaded by dir() on the loaded module
[salt.loaded.int.grains.core:1259][INFO    ][3765414] Although 'dmidecode' was found in path, the current user cannot execute it. Grains output might not be accurate.

Setup
Mater running on a physical machine (not observed by cloud/on-prem VM)
master config

fileserver_backend:
  - gitfs
  - roots
git_pillar_provider: gitpython

ext_pillar:
   - git:
     - __env__ ssh://XXXXXXXXXX/YYYYYYY/ZZZZZZZZZZZ:
       - root: pillar/base

top_file_merging_strategy: merge_all
state_top_saltenv: base
gitfs_provider: gitpython

gitfs_remotes:
  - ssh://XXXXXXXXX/YYYYY/ZZZZZZZ:
    - root: salt/base
  - ssh://XXXXXXXX/YYYYYY/WWWWWWWW:
    - root: ''
gitfs_ref_types:
  - branch
file_roots:
  __env__:
    - /AAAAAAAAAAAA

user: salt
  • on-prem machine
  • onedir packaging

Steps to Reproduce the behavior
We run a scheduled highstate every 5 min, but the error seems to be every minute (which is the git refresh period)

08:51:10,325
08:52:13,526
08:53:16,538
08:54:19,486
08:55:22,681
08:56:25,977
08:57:29,077
08:58:32,050
08:59:34,983
09:00:38,172
09:01:41,231
09:02:44,244
09:03:47,302
09:04:50,191
09:05:53,066
09:07:05,845
09:09:08,795
09:10:12,008
09:11:15,338
09:12:18,487
09:13:21,538
09:14:24,422
09:15:27,661

Expected behavior
No errors reported, or they are in the minion log (not master)

Versions Report

salt --versions-report
Salt Version:
          Salt: 3006.7

Python Version:
        Python: 3.10.13 (main, Feb 19 2024, 03:31:20) [GCC 11.2.0]

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 4.0.11
     gitpython: 3.1.41
        Jinja2: 3.1.3
       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.19.1
        pygit2: Not Installed
  python-gnupg: 0.4.8
        PyYAML: 6.0.1
         PyZMQ: 23.2.0
        relenv: 0.15.1
         smmap: 5.0.1
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: debian 11 bullseye
        locale: utf-8
       machine: x86_64
       release: 5.10.0-18-amd64
        system: Linux
       version: Debian GNU/Linux 11 bullseye```
</details>

**Additional context**
We are running the salt-master as non-root user (salt), and the user does indeed not have access to the full dmidecode information.  The salt-minion is running as root and does have access.  This error log is only observed in the /var/log/salt/master log, it is not present in the /var/log/salt/minion on the master or any other minions.
@jg-basis jg-basis added Bug broken, incorrect, or confusing behavior needs-triage labels Feb 28, 2024
@jg-basis
Copy link
Author

Similar to #59794, but that is for 3002

@nf-brentsaner
Copy link

nf-brentsaner commented Mar 1, 2024

@jg-basis Ah, the memories we shared on that one.

Ideally it'd be nice if deps for dmidecode, virt-what, and smbios (if it's still used?) could be dropped for master daemons entirely.

I'm not sure what they're needed for on a master, but I'd presume most of that usage could be gathered by parsing sysfs (/sys/) and procfs (/proc/) entries directly, many of which are readable by non-root. That would simplify needing to parse the output of e.g. dmidecode, as each "fact" is generally constrained in a single file under those virtual filesystems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior needs-triage
Projects
None yet
Development

No branches or pull requests

2 participants