salt-cloud fails to run as non-root user

[jasonrm]

Post e85e2c2 (Add Salt Cloud roster) I am having the following issue with running salt-cloud as a non-root user.

# on develop (2db74b1)
$ salt-cloud -m cloud.maps.d/dev.conf
[INFO    ] salt-cloud starting
[INFO    ] Applying map from 'cloud.maps.d/dev.conf'.
The following virtual machines are set to be created:
  alex

Proceed? [N/y] y
... proceeding
[INFO    ] Calculating dependencies for alex
[ERROR   ] There was a query error: [Errno 13] Permission denied: '/var/cache'

I'm not sure why it's trying to write to /var, as my config should be overriding the root directory to the current directory.

If I checkout a commit before e85e2c2 I can run the above just fine. When I go back to develop, the destroy is successful despite the error message.

# ... ran successfully on older commit.

# and now back on develop (2db74b1)
$ salt-cloud -m cloud.maps.d/dev.conf -d
[INFO    ] salt-cloud starting
[INFO    ] Applying map from 'cloud.maps.d/dev.conf'.
The following virtual machines are set to be destroyed:
  ec2:
    ec2:
      alex

Proceed? [N/y] y
... proceeding
[INFO    ] Destroying in non-parallel mode.
[INFO    ] [{'instanceId': 'i-4e894aa7', 'currentState': {'code': '32', 'name': 'shutting-down'}, 'previousState': {'code': '16', 'name': 'running'}}]
[ERROR   ] There was an error destroying machines: [Errno 13] Permission denied: '/var/cache'

I'm suspicious of how salt.syspaths doesn't seem to be aware of the config in Saltfile and cloud config files, but that's all I've got at the moment.

Config Files

Saltfile

salt:
  config_dir: .
salt-ssh:
  config_dir: .
salt-key:
  config_dir: .
salt-cloud:
  config_dir: .
salt-master:
  config_dir: .

cloud

minion:
    master: salt-master
root_dir: ./

Versions

# develop branch
$ salt --versions
           Salt: 2014.7.0-1758-g2db74b1
         Python: 2.7.8 (default, Oct  3 2014, 20:39:45)
         Jinja2: 2.7.3
       M2Crypto: 0.22
 msgpack-python: 0.4.2
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.11
          ioflo: Not Installed
          PyZMQ: 14.4.1
           RAET: Not Installed
            ZMQ: 4.0.5
           Mako: Not Installed

[techhat]

@jasonrm as of that commit, Salt Cloud has started keeping an index of instances that it manages, in /var/cache/salt/cloud. Either opening up permissions on /var/cache so that that user can create its directories, or creating /var/cache/salt/cloud with the appropriate permissions should clear up the errors.

Do you normally run the salt command as non-root (using client ACL or somesuch) as well?

[jasonrm]

I agree that I could open up permissions, but that seems to ignore (at least in my mind) the main purpose of being able to set root_dir.

I don't need to run as a non-root user, although I prefer it for various reason. One being that I have multiple salt environments that I am currently working with. Thus, I want to have everything related to each environment contained within it's own set of directories. Running salt-master as non-root has, so far, worked just fine using the same Saltfile + config file approach.

[rallytime]

@jasonrm Does #26200 help alleviate this issue? I could certainly be misunderstanding this, but I though it might help.

[douardda]

Same here, why salt-cloud does not honor the root_dir, cachedir and sock_dir configurations?

What's the status of this issue?

PS: I'm using 2015.8.1

[rallytime]

Unfortunately, I don't think anyone has had a chance to tackle this issue yet.

[tlc]

I was hoping to use salt-cloud and salt-ssh on a cloud project, but this is a deal breaker.
There is no need to have root perms on a machine to manage other machines.

If someone tells me it's a straightforward fix and gives me a strong hint of where
to look, I might try to create a pull request. But for now, I'm going to evaluate Ansible. :(

[thatch45]

@techhat can you or @cro take a look at this one?

[techhat]

As with other components of Salt, Salt Cloud uses syspaths.CACHE_DIR, which defaults to os.path.join(ROOT_DIR, 'var', 'cache', 'salt'). This can be seen in the init_cachedir() function inside salt.utils.cloud.

@cro, do you have any insight as to how other subsystems write to the cache directory as a non-root user?

In the meantime, creating /var/cache/salt/cloud and changing the user/group to whatever no-root user you're using should help.

[meggiebot]

Let's try to get this fixed in 2016.3.3 and 2015.8.12

[jerrykan]

I am experiencing a similar issue with sock_dir defaulting to /var/run/salt/ instead of <root_dir>/var/run/salt/. I am assuming that sock_dir doesn't need to be explicitly configured in the master config file to work with root_dir? or will the sock_dir still need to be configured even if this issue is fixed?

edit: I think I am hitting another issue which I have just created #34806 - but I am still curious whether the sock_dir will need to be explicitly set when both these issues are fixed.

[thor]

Hi folks! Coming across this, I have to ask whether this has been simply closed for inactivity? It would be nice to have a fix for this, especially for the use-case provided by jasonrm.

[gtmanfred]

This was fixed by #35483 and then closed.

[gtmanfred]

If you have a new issue please open a new ticket.