Thanks for the report and sorry for the delay in replying.
I did a quick test here and tried to reproduce the bug using a Jammy VM.
Here's what I did:
# mkdir tmp1 tmp2
# for i in $(seq 20); do > tmp1/${i}; done
# chmod -R +t tmp1
# rsync -avz tmp1/ tmp2/
Everything seemed to work fine. It's important to say that I'm not
using ZFS here, but from your description I got the impression that you
aren't either; am I correct in assuming this?
Could you please provide a reproducer for this bug? Also, it would be
nice if you could confirm whether this still happens on Impish/Jammy.
Thanks.
** Changed in: rsync (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
Incomplete
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
