Community Packages

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!
Tasklist

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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Daniel Wallace (gtmanfred)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

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
Comment by Sébastien Luttringer (seblu) - Thursday, 20 March 2014, 21:05 GMT
The community package run salt-master as salt user since the beginning. Changing the default running user was inspired by the recommendation from the docs:
"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
Comment by Joseph Hall (jphall) - Thursday, 20 March 2014, 21:15 GMT
This is an interesting issue, which has also been discussed in the past at https://github.com/saltstack/salt/issues/6746 . I run my own masters as root, but I do so as a developer (I also run out of git, and not the Arch package). I'll be interested to see your final decision, @seblu.
Comment by niels abspoel (aboe) - Thursday, 20 March 2014, 21:16 GMT
Yes, that is true, the community package has had this feature from the beginning.
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.



Comment by Thomas S Hatch (thatch45) - Thursday, 20 March 2014, 22:27 GMT
Thanks for bringing this to my attention, of course, as far as SaltStack is concerned the distributions of course have full prerogative to decide on how to package all software, but I hope these documentation updates will lend some clarity on this subject:
https://github.com/saltstack/salt/commit/21c4344f2ebe94890ac15e3c913e986ebd818d99
https://github.com/saltstack/salt/commit/370d9718e86e236aa1be9d31d24b6fd752620cd1
Comment by Sébastien Luttringer (seblu) - Thursday, 20 March 2014, 23:36 GMT
Thanks for the update. Makes upstream recommendation more clear.

Loading...