Bug 1415949 - When katello-backup is stored on NFS share exported with the root_squash option it fails on chown operation [NEEDINFO]
Summary: When katello-backup is stored on NFS share exported with the root_squash opti...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Backup & Restore
Version: 6.2.6
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: Unspecified
Assignee: Christine Fouant
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-24 08:02 UTC by Michal Dekan
Modified: 2020-07-16 09:08 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-24 20:35:02 UTC
Target Upstream Version:
apanagio: needinfo? (cfouant)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 18331 0 Normal Closed When katello-backup is stored on NFS share exported with the root_squash option it fails on chown operation 2021-02-09 16:11:52 UTC
Red Hat Knowledge Base (Solution) 2972421 0 None None None 2017-03-17 10:39:08 UTC

Description Michal Dekan 2017-01-24 08:02:47 UTC
Description of problem:

When katello-backup is stored on NFS share exported with the root_squash option it fails on chown operation.

This means that for the destination directory, where the backup will be finally saved, the user creating the backup is no longer root, it is user nobody. Therefore, in the way you are running the backup, it is run by root as far as reading files from the system is concerned, but when it comes to writing files to the destination directory, the user is "squashed" to nobody.

Version-Release number of selected component (if applicable):

Satellite 6.2.x

How reproducible: 100%

Steps to Reproduce:
1. Setup NFS share with root_squash option
2. Call katello-backup on that directory
3. # katello-backup --online-backup /mnt/backup/20170103-root
Creating backup folder /mnt/backup/20170103-root
/usr/share/ruby/fileutils.rb:1341:in `chown': Operation not permitted - /mnt/backup/20170103-root (Errno::EPERM)
        from /usr/share/ruby/fileutils.rb:1341:in `chown'
        from /usr/share/ruby/fileutils.rb:1034:in `block in chown'
        from /usr/share/ruby/fileutils.rb:1033:in `each'
        from /usr/share/ruby/fileutils.rb:1033:in `chown'
        from /bin/katello-backup:48:in `<main>'

Actual results:

As seen above.

Expected results:

Backup taken successfully.

Additional info:

When commenting chown operation in katello-backup and katello-restore backup was taken and restored successfully.

katello-backup

~~~
 46   FileUtils.mkdir_p(@dir)
 47   puts "Creating backup folder #{@dir}"
 48 #  FileUtils.chown(nil, 'postgres', @dir)
 49   FileUtils.chmod 0770, @dir
 50   FileUtils.cd @dir
~~~

katello-restore

~~~
 19 def restore
 20   puts "#{DIR}"
 21 #  FileUtils.chown(nil, 'postgres', DIR)
 22   Dir.chdir(DIR)
~~~

Comment 3 Christine Fouant 2017-01-31 21:16:25 UTC
Created redmine issue http://projects.theforeman.org/issues/18331 from this bug

Comment 4 Alexandros Panagiotou 2017-03-17 10:36:11 UTC
Hello,
I am in the process of creating a KCS article for this BZ. I understand that the chown that fails:

FileUtils.chown(nil, 'postgres', @dir)

is trying to change the ownership of the directory to the database group. To me it seems unsafe to proceed commenting out this line, as I'm worried that the changed ownership may end up in unexpected behaviour at some other point. Since the backup completes, then the main concern is during restoring the backup. Is it possible to tell if a backup created with the line above commented out can be considered reliable?

For now, while there is still this doubt, I consider that it is safer to create the backup on a temporary directory and then move the backup files to the target directory manually.

Regards,
Alexandros

Comment 5 Christine Fouant 2017-03-27 21:33:48 UTC
(In reply to Alexandros Panagiotou from comment #4)
> Hello,
> I am in the process of creating a KCS article for this BZ. I understand that
> the chown that fails:
> 
> FileUtils.chown(nil, 'postgres', @dir)
> 
> is trying to change the ownership of the directory to the database group. To
> me it seems unsafe to proceed commenting out this line, as I'm worried that
> the changed ownership may end up in unexpected behaviour at some other
> point. Since the backup completes, then the main concern is during restoring
> the backup. Is it possible to tell if a backup created with the line above
> commented out can be considered reliable?
> 
> For now, while there is still this doubt, I consider that it is safer to
> create the backup on a temporary directory and then move the backup files to
> the target directory manually.
> 
> Regards,
> Alexandros

Changing the ownership will be required to backup the postgres database while doing an online backup. A temporary workaround could be either to change the chmod command from 0770 to 0777, or to do an offline backup. This BZ is one of the next in my queue, so there will be a longer term solution coming up soon.

Comment 6 Alexandros Panagiotou 2017-04-19 13:21:48 UTC
Hi,
First of all thanks for confirming what the side-effects of the chown can be. I just want to make sure we are on the same page here. The workaround is:

[1] Comment out the chown (as this will fail if not commented out)

[2] Change chmod from 0770 to 0777 or do an offline backup.

What puzzles me, is that both in the case of the reproducer and in the case of the customer, the backup succeeds without the additional change of the chmod (i.e. removing chown allows katello-backup to finish)

Regards,
Alexandros

Comment 7 Christine Fouant 2017-05-17 19:58:27 UTC
(In reply to Alexandros Panagiotou from comment #6)
> Hi,
> First of all thanks for confirming what the side-effects of the chown can
> be. I just want to make sure we are on the same page here. The workaround is:
> 
> [1] Comment out the chown (as this will fail if not commented out)
> 
> [2] Change chmod from 0770 to 0777 or do an offline backup.
> 
> What puzzles me, is that both in the case of the reproducer and in the case
> of the customer, the backup succeeds without the additional change of the
> chmod (i.e. removing chown allows katello-backup to finish)
> 
> Regards,
> Alexandros

It is my understanding that the restoration will fail; however, I am going to verify this information with Chris Roberts.

Comment 8 Chris Roberts 2017-05-24 14:30:53 UTC
I agree with Christine on this will fail, the workaround is to use the chmod command from 0770 to 0777, or to do an offline backup. You could also do a chgrp to postgres which would keep the owner as root.

Comment 9 Chris Roberts 2017-05-24 14:32:15 UTC
* But allow postgres to write to the dir


Note You need to log in before you can comment on or make changes to this bug.