Created attachment 575018 [details]
Test ebuild to selectively enable master/minion functionality
I'm experimenting with using Salstack as a distributed configuration management system (amongst other things).
I had no trouble setting up a master and associating with it a few Debian minions. However I saw that on Gentoo installing app-admin/salt installs automatically the complete package. There is no possibility of specifying what to install: master, minion, api, ...
I reported this on Saltstack Github tracker but it got rejected, static that the Saltstack ebuilds are maintained by Gentoo directly. See https://github.com/saltstack/salt/issues/52725.
I see this as a potential major security risk: why should be the master be installed on every systems? Only salt-minion and salt-call should be installed.
I tried experimenting a bit with the ebuild but I'm definitively not an advanced Gentoo user, so I don't know what I'm supposed to tweak exactly.
I managed to only install the SERVICE salt-minion. The command salt-master is however in any case installed.
I don't think installing the complete package and then doing a rm /usr/bin/salt-master is the proper way to fix this. This should somehow be fixed IMHO in the line
(but I don't know what I should change)
Using Saltstack boostrap install could be an option. However it appears that app-admin/salt-9999 was removed from the tree due to it being broken / unmaintained (see https://gitweb.gentoo.org/repo/gentoo.git/log/app-admin/salt?showmsg=1).
I'm not sure if using "pip install salt" would only install the minion or also the master. I didn't see any "salt-minion" or "salt-master" package so I assume it would install exactly the same components as the ebuild.
Could the Bugtracker moderators please add the ebuild responsible to this bug so that he also receives the notifications? From what I could gather the ebuild maintainer should be "Patrick McLean".
This is not ebuild specific, the ebuild only does the exact same thing "pip install salt" would do, which is functionally equivalent to running "python setup.py install" from the source tree.
There are really only 2 possible approaches to solve this:
- delete the code after the fact (though deleting the command from the system will do very little, as almost all the relevant code lives in the modules). This is the "rm -f /usr/bin/salt" you mentioned above. This approach only removes the command-line wrapper, not the module code that actually implements the master.
- heavily patch the setup.py to make it selectively install only what is needed for a particular configuration. This has the problem of determining what parts of the module code are needed for which configuration and the maintenance burden of maintaining said patch.
So I assume you don't see that installing salt-master on every system is a potential security risk?
Is it possible to somehow blacklist the service, the /usr/bin/salt-master from executing? Or possibly some iptables rules to reject all incoming connections?