Bug 1894485

Summary:	rsync is unable to set permissions when chrooted
Product:	[Fedora] Fedora	Reporter:	Tom Hughes <tom>
Component:	rsync	Assignee:	Michal Ruprich <mruprich>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	afrosi, code, luhliari, mruprich, ssorce
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	rsync-3.2.3-3.fc33	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-12-10 01:15:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Hughes 2020-11-04 11:09:12 UTC

Description of problem:

If "use chroot= yes" is set for the server then it will be able to set permissions on received files.

The problem is that glibc in F33 now implements lchmod, but badly by emulation using /proc, and that fails in a chroot as /proc is not available.

In F32 glibc didn't implement lchmod and rsync's configure script fell back to an alternative way of setting the permissions.

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

glibc-2.32-1.fc33.x86_64

Steps to Reproduce:
1. Create a server target with chroot enabled
2. Sync a file to it
3. See that the permissions are wrong

Actual results:

Permissions are set to 0600.

Expected results:

Permissions are set to match the source, or whatever "incoming chmod" said to set them to.

Additional info:

Already reported in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109 and as a glibc issue at https://sourceware.org/bugzilla/show_bug.cgi?id=26401.

Comment 1 Tom Hughes 2020-11-04 11:12:00 UTC

Also upstream at https://github.com/WayneD/rsync/issues/109 and rsync upstream has now disabled lchmod for linux in https://github.com/WayneD/rsync/commit/85b8dc8abaca96fc3ea7421e09101b6ac41b6718.

Comment 2 Michal Ruprich 2020-12-08 08:39:59 UTC

Hi Tom,

thanks for the report, fix is on the way. I am testing the improved upstream fix right now: https://github.com/WayneD/rsync/commit/9dd62525f3b98d692e031f22c02be8f775966503

Comment 3 Fedora Update System 2020-12-08 12:24:41 UTC

FEDORA-2020-d34606ef29 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d34606ef29

Comment 4 Michal Ruprich 2020-12-08 12:26:26 UTC

*** Bug 1904344 has been marked as a duplicate of this bug. ***

Comment 5 Fedora Update System 2020-12-09 02:20:50 UTC

FEDORA-2020-d34606ef29 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d34606ef29`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d34606ef29

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2020-12-10 01:15:14 UTC

FEDORA-2020-d34606ef29 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.