saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Install Salt from the Salt package repositories here:
https://docs.saltproject.io/salt/install-guide/en/latest/
Apache License 2.0
14.19k stars 5.48k forks source link

[DOCS] can not run salt-minion as unprivileged #59955

Open 787771075 opened 3 years ago

787771075 commented 3 years ago

can run salt-master as unprivileged it is OK Snipaste_2021-04-02_18-05-44

but can not run salt-minion as unprivileged, Always display a root user Snipaste_2021-04-02_18-08-15

my config Snipaste_2021-04-02_18-06-45 Snipaste_2021-04-02_18-10-10

welcome[bot] commented 3 years ago

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey. Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. If you have additional questions, email us at core@saltstack.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!

sagetherage commented 3 years ago

@787771075 where in the docs are you seeing this? Can you please post the docs link, as well? and then what are you trying to execute with a minion as a non-root user? Thank you!

787771075 commented 3 years ago

@sagetherage Thank you for your answer docs url:https://docs.saltproject.io/en/latest/ref/configuration/nonroot.html non-root user is safety requirements Only ordinary users and give sudo permission run salt-master as unprivileged is OK, all process is use ordinary users Can minion be the same as that

lukasraska commented 3 years ago

@787771075 The problem probably lies within systemd configuration, as the service is specified to run as root, but all salt subprocesses are created under the user specified in config. Can you adding following into systemctl edit salt-minion and then restarting the service? (might be needed to chown the files/directories under the specified user again)

[Service]
User=fuhex

I've tested it locally and it works for me, however there might be limitations with the execution modules support for sudo. But the minion runs under the specified user at least.

ggiesen commented 3 years ago

Yes as far as I'm aware there's currently no sudo capability for an minion to escalate privileges when required. That being said, there is a SEP (Salt Enhancement Proposal) to add this functionality (or something similar):

https://github.com/saltstack/salt-enhancement-proposals/pull/35

787771075 commented 3 years ago

@lukasraska thank for your answer Snipaste_2021-04-07_10-19-22 after systemctl edit salt-minion is error but all use root ,it is OK

It seems that this feature is missing,Well, the master works so well

787771075 commented 3 years ago

@ggiesen thank you answer Only after the bill passes, Do they have this function? We'll have to wait.

garethgreenaway commented 3 years ago

Copying comments from Community Slack into the Github issue:

Lachlan Munro 22 hours ago I'd guess that the minion isn't going to cope well with Only ordinary users and give sudo permission, "feels" like the author might not quite understand what they are asking for. I'd imagine you could invent a user and grant them permission to only do particular things but I've never tried and it feels like it would be quite painful. :slightly_smiling_face: 1

Also sent to the channel Lukas Raska 20 hours ago The issue in particular is systemd-specific I believe. The service starts under root, then all subprocesses are spawned under the user specified in configuration. With setproctitle installed, one can see that for salt-master process, there are following "subprocessed: ProcessManager MultiprocessingLoggingQueue TCPPubServerChannel (for TCP transport) EventPublisher Maintenance FileserverUpdate ReqServer_ProcessManager MWorker-* all run under the configured user, and that's it. However for salt-minion, its: KeepAlive MultiMinionProcessManager MinionProcessManager KeepAlive MultiprocessingLoggingQueue which run under the specified user, however there is the main salt-minion process, without any process title specified, which runs under root - because in systemd it's configured to run under root -> while every subprocess runs under the user specified in config, the main process which coordinates everything, still runs under root. To avoid that, one can do systemctl edit salt-minion and specify [Service] User=salt in the override (in this case it's user salt). With this, everything runs as it should: root@salt-test:~# ps uax|grep salt-minion salt 1518954 0.0 0.0 47756 30364 ? Ss 20:41 0:00 /usr/bin/python3 /usr/bin/salt-minion salt 1518957 0.0 0.0 983120 54704 ? Sl 20:41 0:00 /usr/bin/python3 /usr/bin/salt-minion KeepAlive MultiMinionProcessManager MinionProcessManager salt 1518959 0.0 0.0 124316 25776 ? S 20:41 0:00 /usr/bin/python3 /usr/bin/salt-minion KeepAlive MultiprocessingLoggingQueue So probably the docs can be updated to reflect this? The same thing can be done for salt-master process, to avoid initial startup under root altogether. I can prepare some PR to address this in docs, WDYT @ScriptAutomate?

ScriptAutomate commented 3 years ago

Yes as far as I'm aware there's currently no sudo capability for an minion to escalate privileges when required. That being said, there is a SEP (Salt Enhancement Proposal) to add this functionality (or something similar):

saltstack/salt-enhancement-proposals#35

^ This is a good point, here. I'd be for a docs update that walks through setting this up with minion, but I'd also be hesitant on what may come from the outcome of the SEP, and if that would require another rewrite/update of docs. We'd also likely need to have testing in place to run across multiple OS I'd imagine, to confirm that it works as expected across different distros.