Red Hat Bugzilla – Bug 1388145
katello-backup changes ownership of existing directories when used as destination.
Last modified: 2017-05-01 09:55:35 EDT
Description of problem: When running katello-backup /var/tmp (example) it changes ownership & rights of that directory Version-Release number of selected component (if applicable): [root@satellite62 virt-who.d]# yum provides /bin/katello-backup Loaded plugins: product-id, search-disabled-repos, subscription-manager katello-common-3.0.0-13.el7sat.noarch : Common runtime components of katello Repo : @rhel-7-server-satellite-6.2-rpms Matched from: Filename : /bin/katello-backup How reproducible: 100% Steps to Reproduce: 1. login to satellite62 server. 2. become root 3. run katello-backup --skip-pulp-content /var/tmp Actual results: Ownership of /var/tmp is changed to: drwxrwx---. 2 root postgres which consequently breaks the startup of foreman-tasks Expected results: Don't change ownership of existing directories. Additional info: Suggested solution: - Don't change ownership. - If cared about ownership for some reason, fail with suggestion on ownership and/or creation of a new directory
The solution for https://bugzilla.redhat.com/show_bug.cgi?id=1377636 solves this issue.
Please add verifications steps for this bug to help QE verify
Verification steps: - Choose an existing directory to back up to (i.e. /tmp/backup), look at its ownership values - Create a backup as root pointing at that existing directory (i.e. # katello-backup /tmp/backup) - Verify the existing directory has its original ownership values (i.e. /tmp/backup ownership has not changed since the backup initiated)
Verified on Sat 6.2.9-1, as katello-backup now dumps data into a subdirectory, the destination's ownership is not altered. Checked with /var/tmp: ~]# ll /var drwxrwxrwt. 4 root root 4096 Mar 24 08:19 tmp ... ~]# katello-backup --skip-pulp-content /var/tmp ... ~]# ll /var drwxrwxrwt. 5 root root 4096 Mar 24 08:23 tmp ~]# ll /var/tmp drwxrwx---. 2 root postgres 4096 Mar 24 08:23 katello-backup-2017-03-24T08:22:33-04:00
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1191