pulpcore-manager cannot be run by 'pulp' user
The PULP_SETTINGS environment variable is not being set therefore the pulpcore-manager command cannot be run by the
#2 Updated by firstname.lastname@example.org 3 months ago
We can implement this fairly easily, but in order to fully address the issue, we have 2 more pieces of work to do:
- Do we activate the virtualenv by default? Or prompt users to do that in the login message?
- The pulp user intentionally has its shell set to /sbin/nologin for security. Do we want to change it? The current best workaround is
sudo su - pulp --shell /bin/bash
#4 Updated by email@example.com 3 months ago
We propose solving this this way:
- pulpcore-manager is setuid to pulp. The rest of the octal permissions make it so only the pulp user & group can run it. (This eliminates users accidentally running it as root, and having files on disk owned by root rather than pulp. It also makes the shell irrelevant.)
- We configure the virtualenv to set the environment variable. (A .bashrc would not be usable with setuid.)
This way, users can just run the pulpcore-manager binary directly from the full file path like
/usr/local/lib/pulp/bin/pulpcore-manager. Since doing so should include activating the venv, and will be setuid pulp.
#5 Updated by firstname.lastname@example.org 3 months ago
An alternative implementation to #1 was suggested by Ewoud:
AFAIK you can't make a script setuid. Only compiled binaries. I doubt that's worth the effort.
For comparison, in Foreman we have foreman-rake which does the user switching via su if the username is not foreman.
Another thing we set in the wrapper is RUBYOPT=-W0 which disables (deprecation) warnings. This gives a better user experience. Python may have something similar that you can consider.
I think he's wrong about setuid having that limitation, but I like the foreman-rake approach better than setuid.
When installed via RPM, is pulp still running in a venv? If not, this rules out the "set-envvar-in-venv" solution.
I agree, but the RPM packaging could set it somehow also. One assumes root and the other doesn't so I kind of think the installer needs to handle it as the venv, and the RPMs need to handle with their assumption of what users run this command. Wdyt?
#15 Updated by mdellweg about 1 month ago
- Status changed from POST to MODIFIED
Applied in changeset ansible-pulp|880d68dddcbc294ff8e699706cc2654569e5aaa1.
Please register to edit this issue