Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#39559 - [salt] salt-master running as user salt blocks halite and eauth pam
Attached to Project:
Community Packages
Opened by niels abspoel (aboe) - Thursday, 20 March 2014, 19:52 GMT
Last edited by Sébastien Luttringer (seblu) - Thursday, 27 March 2014, 00:34 GMT
Opened by niels abspoel (aboe) - Thursday, 20 March 2014, 19:52 GMT
Last edited by Sébastien Luttringer (seblu) - Thursday, 27 March 2014, 00:34 GMT
|
DetailsDescription:
The new salt package in community has the salt-master running as uprivileged user salt. This blocks external authentication and the use of halite (webgui). Additional info: package version: 2014.1.1 Config and/or log files etc. /etc/salt/master: # The user under which the salt master will run. Salt will update all # permissions to allow the specified user to run the master. The exception is # the job cache, which must be deleted if this user is changed. If the # modified files cause conflicts set verify_env to False. user: salt Steps to reproduce: 1. add the following to /etc/salt/master (please two space indentation) the user must be present on the system with a password external_auth: pam: [username]: - .* - '@runner' - '@wheel' 2. run this command: salt -a pam \* test.ping it will ask a username and password provide the username as stated in the config file and the password This mechanism is also used in halite to login the webinterface. The reason is eauth needs to be root to access pam. The Suse package and Centos package of salt keep salt running as root by default. Why not keep this file in it's default configuration? |
This task depends upon
Closed by Sébastien Luttringer (seblu)
Thursday, 27 March 2014, 00:34 GMT
Reason for closing: Fixed
Additional comments about closing: 2014.1.1-2
Thursday, 27 March 2014, 00:34 GMT
Reason for closing: Fixed
Additional comments about closing: 2014.1.1-2
"While the default setup runs the master and minion as the root user, it is generally wise to run the master as an unprivileged user."[1]
I took the wise path, it's a safer default (for a remote accessible daemon) and it's easier to revert to running master as root than moving to running as non-root (creating users, change file permissions in /etc, remove old cache).
If I understand correctly, you use a features that seems to require salt-master to be run as root and you have to change user=salt by user=root in /etc/salt/master, and everything works, right?
[1] http://docs.saltstack.com/topics/nonroot.html
but the original package made by Thomas: https://aur.archlinux.org/packages/salt-git/
doesn't change the default configuration file from upstream.
It maybe wise to run salt-master as non-root, the only change would be
in /etc/salt/master. this change be it from root to user or back is al the same.
Salt will take care of the rest of the permissions, no need to set this in the package.
I think it is a good idea to look at the packages from ubuntu/centos/suse to let the archlinux package
behave the same way.
https://github.com/saltstack/salt/commit/21c4344f2ebe94890ac15e3c913e986ebd818d99
https://github.com/saltstack/salt/commit/370d9718e86e236aa1be9d31d24b6fd752620cd1