-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Non-root Users Unable to Review Job Status #55275
Comments
This is a problem we're seeing in several environments here as well and it shows a general architectural issue of the SaltStack CLI tooling IMHO. |
im able to replicate this when the salt-master/salt-minion processes started up via root. When i start them up via the same user it does work, but we want it to work while running salt via root. will need to get this fixed up. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
not stale |
Thank you for updating this issue. It is no longer marked as stale. |
Still not stale. |
@petiepooo no more stalebot -- this is open and will remain so |
Description of Issue
Followed instructions to setup non-root users with the ability to run jobs as specified at https://docs.saltstack.com/en/latest/ref/publisheracl.html
Running jobs as non-root user completes as expected:
Similarly, running jobs using the
--async
flag works as expected:However, attempting to view previous jobs results using
salt-run jobs.lookup_jid <x>
or thesalt.client.LocalClient.get_cli_returns
function fails. Example:Per the linked documentation, reviewing the root level directory shows expected permissions:
However, the
return.p
file shows it is read+write by root only:Setup
Standard RPM installation on an AWS EC2 instance running Amazon Linux 2. Configured to allow ec2-user to run all states on all nodes as following in
/etc/salt/master
:Executed
chmod 755 /var/cache/salt /var/cache/salt/master /var/cache/salt/master/jobs /var/run/salt /var/run/salt/master
as indicated in linked documentation.Possible Solution
Issue seems to stem from the following:
salt/salt/utils/atomicfile.py
Line 132 in 01b9405
Ultimately, the
return.p
file is created as a new temporary file, which I assume is given the permissions read+write to root only. Once the temporary file is written and the context handler completes what it needs with the file, theclose
function is invoked and the temporary file is moved (os.rename
on *nix) to the correct job cache location. Since it's moved, the original permissions are retained.As a temporary workaround, I modified
atomicfile.py
as follows:salt/salt/utils/atomicfile.py
Line 101 in 01b9405
Instead of
os.rename
, I useshutil.copyfile
salt/salt/utils/atomicfile.py
Line 132 in 01b9405
After the rename occurs, I call
os.remove(self._tmp_filename)
I have not fully tested this to identify long-term ramifications, but wanted to highlight a possible fix for others in a similar situation. While using an external job cache would likely be a better long-term solution, the documentation implies this should be possible.
Additionally, in some circumstances, there appear to be other non-critical issues - for example, in some scenarios, the following occurs when querying the job ID even after the fixes identified above:
Note the information is still returned, but it appears a new job is trying to be created but cannot be. Likely unrelated and probably needs a separate issue, but wanted to document here.
Versions Report
The text was updated successfully, but these errors were encountered: