[Bug 1912950] [NEW] rsync halts with Permission denied (13) with a sticky dir and only recent kernels

[Mathieu L BOUCHARD]

Public bug reported:

Looks like rsync should be adapted to a new policy of the Linux kernel.
I found a report in the ZFS Github that looks a lot like my problem :
https://github.com/openzfs/zfs/issues/10742 But on that page, the
suggested solution using /proc/sys/fs/protected_regular doesn't seem to
be ideal and instead rsync should be able to figure it out by itself so
that users aren't encouraged to keep that security measure turned off
(perhaps my idea is bad, but pros and cons have to be figured out).

I'm regularly backing up a remote folder on a machine that has a
different user list and that folder has sticky bit set, while being root
on both sides. I had no error using Ubuntu 18.04 : it started failing
just after upgrading to 20.04. If I try to rsync individual files of
that folder, I get error 13 in most cases, but if I chmod -t on that
folder, I can rsync them, but if I try rsyncing the folder again (by
recursion), rsync does chmod +t on it before rsyncing individual files
in the folder, and then it fails again. And of course, to work around
the problem, rsync would probably have to catch error 13 and retry after
doing chmod -t temporarily on the folder, then schedule a chmod +t after
this folder is finished syncing, or at cleanup time (Ctrl+c or SIGTERM).

** Affects: rsync (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  Looks like rsync should be adapted to a new policy of the Linux kernel.
  I found a report in the ZFS Github that looks a lot like my problem :
  https://github.com/openzfs/zfs/issues/10742 But on that page, the
  suggested solution using /proc/sys/fs/protected_regular doesn't seem to
  be ideal and instead rsync should be able to figure it out by itself so
  that users aren't encouraged to keep that security measure turned off
  (perhaps my idea is bad, but pros and cons have to be figured out).
  
  I'm regularly backing up a remote folder on a machine that has a
  different user list and that folder has sticky bit set, while being root
  on both sides. I had no error using Ubuntu 18.04 : it started failing
  just after upgrading to 20.04. If I try to rsync individual files of
  that folder, I get error 13 in most cases, but if I chmod -t on that
- folder, I can rsync them, but after that, if I try rsyncing the folder
- again, rsync does chmod +t on it before rsyncing individual files in the
- folder, and then it fails again. And of course, to work around the
- problem, rsync would probably have to catch error 13 and retry after
+ folder, I can rsync them, but if I try rsyncing the folder again (by
+ recursion), rsync does chmod +t on it before rsyncing individual files
+ in the folder, and then it fails again. And of course, to work around
+ the problem, rsync would probably have to catch error 13 and retry after
  doing chmod -t temporarily on the folder, then schedule a chmod +t after
  this folder is finished syncing, or at cleanup time (Ctrl+c or SIGTERM).

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1912950

Title:
  rsync halts with Permission denied (13) with a sticky dir and only
  recent kernels

Status in rsync package in Ubuntu:
  New

Bug description:
  Looks like rsync should be adapted to a new policy of the Linux
  kernel. I found a report in the ZFS Github that looks a lot like my
  problem : https://github.com/openzfs/zfs/issues/10742 But on that
  page, the suggested solution using /proc/sys/fs/protected_regular
  doesn't seem to be ideal and instead rsync should be able to figure it
  out by itself so that users aren't encouraged to keep that security
  measure turned off (perhaps my idea is bad, but pros and cons have to
  be figured out).

  I'm regularly backing up a remote folder on a machine that has a
  different user list and that folder has sticky bit set, while being
  root on both sides. I had no error using Ubuntu 18.04 : it started
  failing just after upgrading to 20.04. If I try to rsync individual
  files of that folder, I get error 13 in most cases, but if I chmod -t
  on that folder, I can rsync them, but if I try rsyncing the folder
  again (by recursion), rsync does chmod +t on it before rsyncing
  individual files in the folder, and then it fails again. And of
  course, to work around the problem, rsync would probably have to catch
  error 13 and retry after doing chmod -t temporarily on the folder,
  then schedule a chmod +t after this folder is finished syncing, or at
  cleanup time (Ctrl+c or SIGTERM).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1912950/+subscriptions