Project

Profile

Help

Issue #7459

closed

Make the pulp exporter directories rwx for pulp group

Added by paji@redhat.com over 4 years ago. Updated about 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
-
Category:
-
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 81
Quarter:

Description

Directories generated via pulp3 while exporting tend to have rwx access for the pulp user but not the pulp group.

$  ls -ld /var/lib/pulp/exports/Default_Organization/kresteva/1.0/bar1/2020-09-04T02-30-40-00-00
drwxr-xr-x. 2 pulp pulp 152 Sep  4 02:30 /var/lib/pulp/exports/Default_Organization/kresteva/1.0/bar1/2020-09-04T02-30-40-00-00

Note that group write is missing for this directory. Katello wants to be able to add additional json files to that directory and hence needs write access to the pulp group.

Temporarily this can be fixed by

sudo setfacl -Rdm 'g:pulp:rwx' /var/lib/pulp/exports/

but I think pulp group write is the better solution.

Actions #1

Updated by fao89 over 4 years ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 81
Actions #2

Updated by mdepaulo@redhat.com over 4 years ago

We were discussing possible solutions on #pulp-meeting:

  1. Setting group write on /var/lib/pulp/exports/ (or whatever dirs for allowed_exports_paths) is not sufficient because it will not apply to created directories under it.
  2. Setting an ACL for group write default (default ACL is like "inherited") in the installer would solve the problem easily, but users using ext2,3,4 will need to have ACLs enabled in /etc/fstab . And NFSv3 won't support it at all.
  3. umask for the process would solve the problem, but is this feasible?
  4. Updating the application logic to set the perms would solve the problem.
Actions #3

Updated by ggainey over 4 years ago

wrote:

We were discussing possible solutions on #pulp-meeting:

  1. Setting group write on /var/lib/pulp/exports/ (or whatever dirs for allowed_exports_paths) is not sufficient because it will not apply to created directories under it.
  2. Setting an ACL for group write default (default ACL is like "inherited") in the installer would solve the problem easily, but users using ext2,3,4 will need to have ACLs enabled in /etc/fstab . And NFSv3 won't support it at all.
  3. umask for the process would solve the problem, but is this feasible?
  4. Updating the application logic to set the perms would solve the problem.

exporters write to whatever directory is specified for them at creation/update time - we don't know it at install-time, it's entirely possible to define ALLOWED_EXPORT_DIRS as ['/']

It "makes sense" (for whatever that is worth :) ) to me that the application insures that, if it has to createa directory to export-to, it insures that the end result is a directory that both the app-owner and app-group have write-access to.

Actions #4

Updated by pulpbot over 4 years ago

  • Status changed from NEW to POST

Added by ggainey over 4 years ago

Revision 43f50f75 | View on GitHub

When export creates a dir, make sure the group can write to it.

closes #7459

Actions #5

Updated by ggainey over 4 years ago

  • Status changed from POST to MODIFIED
Actions #6

Updated by bmbouter about 4 years ago

  • Sprint/Milestone set to 3.7.0
Actions #7

Updated by pulpbot about 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF