Project

Profile

Help

Issue #7155

pulpcore-manager cannot be run by 'pulp' user

Added by bmbouter 5 months ago. Updated about 1 month ago.

Status:
MODIFIED
Priority:
Normal
Assignee:
Category:
Installer
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 84
Quarter:

Description

The PULP_SETTINGS environment variable is not being set therefore the pulpcore-manager command cannot be run by the pulp user.


Related issues

Has duplicate Pulp - Issue #6263: User installation makes non-pulp user hard to useCLOSED - DUPLICATE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision 880d68dd View on GitHub
Added by mdellweg about 2 months ago

Add pulpcore-admin wrapper

This script sets PULP_SETTINGS and calls pulpcore-admin as pulp user.

fixes #7155 https://pulp.plan.io/issues/7155

Revision 880d68dd View on GitHub
Added by mdellweg about 2 months ago

Add pulpcore-admin wrapper

This script sets PULP_SETTINGS and calls pulpcore-admin as pulp user.

fixes #7155 https://pulp.plan.io/issues/7155

History

#1 Updated by dkliban@redhat.com 4 months 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.

#2 Updated by mdepaulo@redhat.com 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:

  1. Do we activate the virtualenv by default? Or prompt users to do that in the login message?
  2. 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

#3 Updated by rchan 3 months ago

  • Sprint changed from Sprint 79 to Sprint 80

#4 Updated by mdepaulo@redhat.com 3 months ago

We propose solving this this way:

  1. 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.)
  2. 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 mdepaulo@redhat.com 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.

#6 Updated by rchan 3 months ago

  • Sprint changed from Sprint 80 to Sprint 81

#7 Updated by rchan 2 months ago

  • Sprint changed from Sprint 81 to Sprint 82

#8 Updated by dkliban@redhat.com 2 months ago

  • Has duplicate Issue #6263: User installation makes non-pulp user hard to use added

#9 Updated by mdellweg 2 months ago

When installed via RPM, is pulp still running in a venv? If not, this rules out the "set-envvar-in-venv" solution.

#10 Updated by mdellweg 2 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to mdellweg

#11 Updated by pulpbot 2 months ago

  • Status changed from ASSIGNED to POST

#12 Updated by bmbouter 2 months 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?

#13 Updated by rchan about 2 months ago

  • Sprint changed from Sprint 82 to Sprint 83

#14 Updated by rchan about 2 months ago

  • Sprint changed from Sprint 83 to Sprint 84

#15 Updated by mdellweg about 1 month ago

  • Status changed from POST to MODIFIED

Please register to edit this issue

Also available in: Atom PDF