Issue #7459
closed
Make the pulp exporter directories rwx for pulp group
Status:
CLOSED - CURRENTRELEASE
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.
- Triaged changed from No to Yes
- Sprint set to Sprint 81
We were discussing possible solutions on #pulp-meeting:
- 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.
- 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.
- umask for the process would solve the problem, but is this feasible?
- Updating the application logic to set the perms would solve the problem.
mdepaulo@redhat.com wrote:
We were discussing possible solutions on #pulp-meeting:
- 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.
- 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.
- umask for the process would solve the problem, but is this feasible?
- 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.
- Status changed from NEW to POST
- Status changed from POST to MODIFIED
- Sprint/Milestone set to 3.7.0
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Also available in: Atom
PDF
.
When export creates a dir, make sure the group can write to it.
closes #7459