Hi, This is more of a feature request, but... Salt does no privilege separation and runs as root. For the minion root privileges are needed to perform most of its duties, so this is probably not solvable unless some form of privilege separation is applied upstream. For the master on the other hand, which is a network daemon makes this look quite bad. Fortunately the master supports non-root operation and is probably easy to make it run like that. So, it would be cool to have an option in rc.conf for enabling execution of the master. Ideally, this should be the default. See: https://github.com/saltstack/salt/issues/5249 https://github.com/saltstack/salt/issues/6746
There is no rc.conf or port changes needed. Simply create a user and update the master config file with a 'user' entry like this. /usr/local/etc/salt/master user: saltmaster If you just installed Salt and haven't started it yet then you should be good. Otherwise you'll need to ensure /var/cache/salt, /var/run/salt, and /var/log/salt are all owned by the right user. User to user, I think as long as policy from Saltstack is to run as root then it doesn't seem to be port's policy to override that default. The second issue you mentioned was closed by the Salt upstream and until Salt's policy changes then a PR to make a user be default doesn't seem warranted. Like you, I don't agree with Saltstack's policy as I think network facing services should be privilege separated by default. Final call goes to the maintainer of course as to close or keep the PR. See http://docs.saltstack.com/en/latest/ref/configuration/nonroot.html Jason
I understand. I just thought it could be a good idea to have the package allocate a user account and ship with the default configuration using that user. Also, salt 2015.5 ships with support to run the minion under an unprivileged user with sudo on salt-call only. This is nowhere near privsep, but would be better than just defaulting to root IMHO. thanks Luca
My feeling is that I'd prefer to leave the pkg as-is. I'm not aware of any other distribution that defaults to the non-root user, and I prefer to match upstream as much as possible. For those that would prefer to change the default behavior, the upstream documentation is adequate to make the changes as desired.
How about considering a non-default option? I know our users can be more security conscious. Might be a handy 'unique selling proposition' and point of differentiation. @Christer I'll assign this to you so you can progress the issue as you see fit. Let me know if you need help
I believe it is time to close this PR. As I mentioned in comment #1 this is fully documented in the upstream manual on how to configure this. With hat ports-secteam@ on, I feel the end user can follow that and set the one line of configuration needed after making a user. Not sure of the value added proposition for a port option when the configuration introduces nuances documented upstream. Maintainer concurs in comment #3 that an end user can configure as such if they desire the feature.