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

[BUG] Publisher_ACL's doesn't work like expected in 3006 #66067

Open
3 of 9 tasks
david-pulkowski opened this issue Feb 14, 2024 · 1 comment
Open
3 of 9 tasks

[BUG] Publisher_ACL's doesn't work like expected in 3006 #66067

david-pulkowski opened this issue Feb 14, 2024 · 1 comment
Labels
Bug broken, incorrect, or confusing behavior needs-triage

Comments

@david-pulkowski
Copy link

Description
For simplicity. Create a user and create a simple publisher_acl restriction (see below) and run a command not in the publisher ACL. In a previous salt version 3004 for us. The example below would properly give us an authentication issue if we did anything not defined in the publisher_acl. So if you ran

salt '*' test.ping
Authorization error occurred. (the result we would expect)

And

salt '*' pillar.items 

(and the display would be the pillar values as we would expect).

For testing use a simple setup:
Add proper user.

publisher_acl:
  USER-NAME:
	- pillar.items

Run a (with user in publisher_acl

salt '*' test.ping

Expected result:

Authorization error occurred.

Actual result:
Minions ping back.

Setup
create a user & set the publisher_acl to limit the user to be able to run a few salt commands

publisher_acl:
  USER-NAME:
	- pillar.items

switch to the user created and run a

salt '*' test.ping

Then run a

salt '*' pillar.items
  • on-prem machine
  • VM (Virtualbox, KVM, etc. please specify)
  • KVM
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD
  • classic packaging
  • onedir packaging
  • used bootstrap to install

Steps to Reproduce the behavior
(Include debug logs if possible and relevant)

Expected behavior
When a command is run that is allowed it should run. When a command is not specified to be allowed it should be:

Authorization error occurred.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
          Salt: 3006.6

Python Version:
        Python: 3.10.13 (main, Nov 15 2023, 04:34:27) [GCC 11.2.0]

Dependency Versions:
          cffi: 1.16.0
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 4.0.11
     gitpython: 3.1.40
        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.14.2
         smmap: 5.0.1
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: rhel 9.3 Plow
        locale: utf-8
       machine: x86_64
       release: 5.14.0-362.18.1.el9_3.x86_64
        system: Linux
       version: Red Hat Enterprise Linux 9.3 Plow

Additional context
Add any other context about the problem here.

@d3zorg
Copy link

d3zorg commented Oct 28, 2024

upgraded 3005.5 onedir to 3006.9 and having this issue

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