Open jpittiglio opened 5 years ago
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.
The CLI tools are a hybrid of a local process and a remote job execution, so issues like these show up over and over again in various places (e.g. handling of keys through salt-key
etc.).
IMHO, the whole CLI tooling should continuously move towards the goal of not doing any local execution at all, but to merely interact with SaltStack through the master's interface to handle jobs, which are then again completely executed by the Master - the CLI should only be a thin wrapper around all this.
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:
https://github.com/saltstack/salt/blob/01b9405b61cd416d4c852c87bd484759f5ec9c96/salt/utils/atomicfile.py#L132
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: https://github.com/saltstack/salt/blob/01b9405b61cd416d4c852c87bd484759f5ec9c96/salt/utils/atomicfile.py#L101Instead of
os.rename
, I useshutil.copyfile
https://github.com/saltstack/salt/blob/01b9405b61cd416d4c852c87bd484759f5ec9c96/salt/utils/atomicfile.py#L132 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