Issue #7155
closedpulpcore-manager cannot be run by 'pulp' user
Added by bmbouter over 4 years ago. Updated almost 4 years ago.
Description
The PULP_SETTINGS environment variable is not being set therefore the pulpcore-manager command cannot be run by the pulp
user.
Related issues
Updated by dkliban@redhat.com over 4 years ago
- Triaged changed from No to Yes
- Sprint set to Sprint 79
PULP_SETTINGS environment variable needs to be in the pulp user's .bashrc.
Updated by mdepaulo@redhat.com over 4 years 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
Updated by mdepaulo@redhat.com over 4 years 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.
Updated by mdepaulo@redhat.com over 4 years 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.
Updated by dkliban@redhat.com about 4 years ago
- Has duplicate Issue #6263: User installation makes non-pulp user hard to use added
Updated by mdellweg about 4 years ago
When installed via RPM, is pulp still running in a venv? If not, this rules out the "set-envvar-in-venv" solution.
Updated by mdellweg about 4 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to mdellweg
Updated by pulpbot about 4 years ago
- Status changed from ASSIGNED to POST
Updated by bmbouter about 4 years ago
mdellweg wrote:
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?
Added by mdellweg about 4 years ago
Added by mdellweg about 4 years ago
Revision 880d68dd | View on GitHub
Add pulpcore-admin wrapper
This script sets PULP_SETTINGS and calls pulpcore-admin as pulp user.
Updated by mdellweg about 4 years ago
- Status changed from POST to MODIFIED
Applied in changeset ansible-pulp|880d68dddcbc294ff8e699706cc2654569e5aaa1.
Updated by ttereshc almost 4 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Add pulpcore-admin wrapper
This script sets PULP_SETTINGS and calls pulpcore-admin as pulp user.
fixes #7155 https://pulp.plan.io/issues/7155