rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

[Alkis Georgopoulos]

Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it returned "no" before.

Steps to reproduce:

# Emulate /proc not being mounted
$ mount --bind / /mnt
$ chroot /mnt rsync -a /bin/ls .
rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 3) at main.c(1330) [sender=3.2.3]

I reported this issue upstream in https://github.com/WayneD/rsync/issues/109 but the rsync developer says it's a problem in libc, and it might well be.

Simple C code to reproduce the problem without rsync:

printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails when /proc isn't mounted, yet it succeeds if it is mounted.

Python had a similar issue, and they ended up avoiding AC_CHECK_FUNC(lchmod) under Linux:

https://bugs.python.org/issue34652
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

```c
if test "$MACHDEP" != linux; then
  AC_CHECK_FUNC(lchmod)
fi
```

So I'm not sure which package is causing the bug here. Should autoconf return false? Should libc implement lchown without the bug? Or should rsync skip lchmod under Linux, like python did?

[Ldv-c (ldv-c)]

Fixes for https://sourceware.org/bugzilla/show_bug.cgi?id=14578
introduced regressions in cases when /proc is not mounted:
- lchmod used to return ENOSYS, now it returns EOPNOTSUPP;
- fchmodat(AT_SYMLINK_NOFOLLOW) used to return ENOTSUP, now it returns EOPNOTSUPP which is different from ENOTSUP on some architectures, e.g. hppa.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

This is interesting and I appreciate your investigation! I wonder though if there's a third outcome here - that it's not a bug because the glibc implementation of lchmod() requires /proc to be mounted, and if you don't have /proc mounted then by that definition you have a broken system and lchmod() is not expected to work, so rsync won't work, as a design decision of upstream glibc.

I'm not claiming that this is the case, just that it's another case to consider.

[Alkis Georgopoulos (alkisg)]

Hi Robie, thank you for the feedback,

I located an upstream bug report in glibc for this:
https://sourceware.org/bugzilla/show_bug.cgi?id=26401

[Alkis Georgopoulos (alkisg)]

Hello, just noting that rsync in Ubuntu 20.10 is affected by this glibc issue:

https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1902109
https://github.com/WayneD/rsync/issues/109

[Christian Ehrhardt  (paelzer)]

Awesome, thanks for updating the bug tasks and tracking bug already Alkis!

[Tom Hughes (tomhughes)]

Also rsync in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1894485

[Balint Reczey (rbalint)]

IMO both the new and old errors were accurate and this is just a behaviour change in glibc rather than a regression.
Rsync upstream already adapted to the new glibc behaviour and unless glibc upstream reverts the change this will stay the glibc behaviour in Ubuntu, too.

[Balint Reczey (rbalint)]

I'm not sure if the fix is worth backporting to Groovy since /proc is typically mounted.

[Balint Reczey (rbalint)]

I've marked this bug having low importance due to the small set of cases it can surface and the plan for fixing it is syncing the next upstream release from Debian.

[Balint Reczey (rbalint)]

If someone feels that it is still important to fix it Groovy, too, please prepare the fix for 21.04 and follow the SRU procedure with or without sponsorship request: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure .

[Alkis Georgopoulos (alkisg)]

Since this was fixed upstream and it doesn't affect any LTS Ubuntu releases, I don't think it's important enough to do SRUs. Thank you!

(For LTSP users, that are affected by this: once a fixed rsync version lands in Ubuntu, I'll copy it to the LTSP PPA for Groovy, so LTSP will work there too)

[Aaron Meyer (aarmey)]

Actually, as far as I can tell this failure affects a much wider set of cases. I am seeing this on a standard install as long as the (default) "use chroot" option is being used.

[Adhemerval Zanella (adhemerval-zanella)]

I think there is no much glibc can do without proper kernel support [1].

[1] https://sourceware.org/pipermail/libc-alpha/2020-July/116513.html

[Ldv-c (ldv-c)]

Just letting you know that we reverted commit 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d in our glibc build shortly after reporting this issue.

[Adhemerval Zanella (adhemerval-zanella)]

(In reply to Dmitry V. Levin from comment #4)
> Just letting you know that we reverted commit
> 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d in our glibc build shortly after
> reporting this issue.

Reading rsync bug report, I really think that EOPNOTSUPP is the correct error code to return in this case. The configure was done on a build system where lchmod does work (since it has procps mounted). So I do not fully agree this really characterizes as a regression.

And I don't think reverting lchmod support since propcs might be not available is the correct approach, best option would try to ask kernel to have proper syscall support which does not require userland hacks. Rick Felker already sent a patch, but it seems to be stuck.