1930662 – The use of rsync with a user different than root will not restore links during the recovery

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1930662 - The use of rsync with a user different than root will not restore links during the recovery

Summary: The use of rsync with a user different than root will not restore links durin...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	rear
Sub Component:
Version:	8.3
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Pavel Cahyna
QA Contact:	David Jež
Docs Contact:	Prerana Sharma
URL:
Whiteboard:
Depends On:
Blocks:	1947064 1973448
TreeView+	depends on / blocked

Reported:	2021-02-19 11:53 UTC by Welterlen Benoit
Modified:	2024-06-14 00:23 UTC (History)
CC List:	4 users (show)
Fixed In Version:	rear-2.4-19.el8
Doc Type:	Bug Fix
Doc Text:	.rsync with an unprivileged remote user can now be used in ReaR Previously, when rsync was used to back up and restore the system data `(BACKUP=RSYNC)`, the parameters to rsync were incorrectly quoted, and the `--fake-super` parameter was not passed to the remote rsync process. Consequently, the file metadata was not correctly saved and restored. With this update following bugs have been fixed: * ReaR uses the correct parameters for rsync. * Improved rsync code for error detection during backup and restore: If there is a rsync error detected during the backup, ReaR aborts with an error message. If there is a rsync error detected during the restore, ReaR displays a warning message. In the `/etc/rear/local.conf` file set `BACKUP_INTEGRITY_CHECK=1` to turn the warning into an error message.
Clone Of:
Environment:
Last Closed:	2021-11-09 18:53:41 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Github	rear/rear/commit/d90c4904c62844b4813fd6ce240a904fdfb65286	None	None	None	2021-06-28 15:24:56 UTC
Github	rear rear pull 2577	None	closed	Fix rsync --fake-super option on remote server	2022-08-03 09:17:05 UTC
Github	rear rear pull 2632	None	Merged	Cleanup rsync and fix error reporting	2022-08-03 09:17:09 UTC
Red Hat Knowledge Base (Solution)	5894681	None	None	None	2021-03-19 16:07:21 UTC
Red Hat Product Errata	RHEA-2021:4344	None	None	None	2021-11-09 18:53:57 UTC

Description Welterlen Benoit 2021-02-19 11:53:33 UTC

Description of problem:
With a the use of rsync + user, the restore will not recreate links, because of --fake-root option of rsync:

BACKUP_URL=rsync://user1.122.220:/home/user1/rear/

Version-Release number of selected component (if applicable):
rear-2.4-17.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1. rear mkbackup with BACKUP_URL=rsync://user1.122.220:/home/user1/rear/
2. rear recover
3.

Actual results:
All links are replaced by files: (/bin /lib)
---
drwxr-xr-x 18 root root  4096 Feb 15 07:19 .
drwxr-xr-x  4 root root    80 Jan 29 13:16 ..
-rw-------  1 root root     0 Feb 15 07:48 .autorelabel
-rwxrwxrwx  1 root root     7 Apr 23  2020 bin
drwxr-xr-x  6 root root  1024 Jan 29 13:54 boot
drwxr-xr-x 16 root root  4096 Feb 15 07:46 dev
drwxr-xr-x 88 root root  4096 Feb 15 07:48 etc
drwxr-xr-x  3 root root  4096 Apr 23  2020 home
-rwxrwxrwx  1 root root     7 Apr 23  2020 lib
-rwxrwxrwx  1 root root     9 Apr 23  2020 lib64
drwx------  2 root root 16384 Jan 15 10:40 lost+found
drwxr-xr-x  2 root root  4096 Apr 23  2020 media
drwxr-xr-x  3 root root  4096 Feb  9 20:35 mnt
drwxr-xr-x  2 root root  4096 Apr 23  2020 opt
drwxr-xr-x  2 root root  4096 Feb  9 15:59 proc
drwxr-x---  5 root root  4096 Feb 15 07:48 root
drwxr-xr-x  2 root root  4096 Feb  9 16:05 run
-rwxrwxrwx  1 root root     8 Apr 23  2020 sbin
drwxr-xr-x  2 root root  4096 Apr 23  2020 srv
drwxr-xr-x  2 root root  4096 Feb  9 15:59 sys
drwxrwxrwx  2 root root  4096 Feb 15 07:19 tmp
drwxr-xr-x 12 root root  4096 Jan 15 10:46 usr
drwxr-xr-x 21 root root  4096 Jan 15 10:55 var
---

Files are used to store permissions details in xattr but are not restored in recover phase.

Expected results:
We should see links:
---
lrwxrwxrwx.   1 root root    7 Apr 23  2020 bin -> usr/bin
lrwxrwxrwx.   1 root root    7 Apr 23  2020 lib -> usr/lib
lrwxrwxrwx.   1 root root    9 Apr 23  2020 lib64 -> usr/lib64
lrwxrwxrwx.   1 root root    8 Apr 23  2020 sbin -> usr/sbin
---

Additional info:
if we don't use -fake-root, the links are recreated, but the owner is wrong.

I opened this BZ against rsync:
https://bugzilla.redhat.com/show_bug.cgi?id=1930654

Comment 1 Pavel Cahyna 2021-02-24 11:12:32 UTC

Is there anything that can be done in ReaR to improve the situation, except perhaps documenting the problem?

Comment 2 Pavel Cahyna 2021-02-25 17:58:50 UTC

I see that it is actually a problem in ReaR and not in rsync, per PR #2577 and bz1930654. Thanks for the investigation!

Comment 3 Welterlen Benoit 2021-03-05 16:11:43 UTC

Hello,

The easiest solution is to use "-M--fake-super", thus no need of "" around rsync --fake-super

And it's also a workaround to add this in local.conf:

BACKUP_RSYNC_OPTIONS=( "${BACKUP_RSYNC_OPTIONS[@]}" -M--fake-super )

Thanks

Benoit

Comment 4 Welterlen Benoit 2021-04-07 15:13:49 UTC

I updated the KCS, the workaround does not work as the restore will also execute fake-super locally, thus permissions will not be restored...

Comment 10 Pavel Cahyna 2021-06-21 12:43:18 UTC

I submitted a related PR upstream that improves error checking during rsync backup (warning gets promoted to error) and restore (warning gets properly reported and optionally promoted to error).

Comment 12 Pavel Cahyna 2021-07-16 14:13:35 UTC

Steps to reproduce:

1. create an unprivileged user (here called 'user')
2. set up passwordless ssh from root to user
3. install and configure rear - /etc/rear/local.conf should contain

BACKUP=RSYNC
BACKUP_PROG_EXCLUDE=( '/tmp/*' '/dev/shm/*' "$VAR_DIR/output/*" "/home/user/rsyncbackup" )
BACKUP_URL=rsync://user@localhost/home/user/rsyncbackup/

4. mkdir -p /home/user/rsyncbackup/
5. create rear backup
6. verify that the backup files under /home/user/rsyncbackup/ have the  appropriate extended attributes

# getfattr -d -m- /home/user/rsyncbackup/$HOSTNAME/backup/bin
...
user.rsync.%stat="120777 0,0 0:0"
and it should be a regular file, not a symlink - the symlink information is stored in the extended attribute

7. optionally, to test the new error reporting, add a nonsensical option BACKUP_RSYNC_OPTIONS+=( -M--nonsense ) to local.conf and check that rear mkbackup aborts with an error instead of displaying a warning message and continuing.

Comment 22 errata-xmlrpc 2021-11-09 18:53:41 UTC

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 (rear bug fix and enhancement update), 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/RHEA-2021:4344

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