This new behavior is enforced by /proc/sys/fs/protected_regular, a new
sysctl introduced by commit 30aba6656f61ed44cba445a3c0d38b296fa9e8f5
("namei: allow restricted O_CREAT of FIFOs and regular files").The default behavior is to make data spoofing attacks harder, disallowing the open of files not owned by the user in world writable sticky directory (unless the user perfectly matches the owner). Unfortunately this setting is system-wide and it's not per-filesystem. You can restore the previous behavior system-wide by running: $ sudo sysctl fs.protected_regular=0 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1887727 Title: Permission denied opening file in a directory with a sticky bit Status in zfs-linux package in Ubuntu: New Bug description: We just upgraded to Ubuntu 20.04, so we're now running version 0.8.3-1ubuntu12.1 of zfsutils-linux and related packages. We have a backup server that's essentially rsyncing files from remote systems. After the upgrade we started getting Permission denied failures on a few files, which match a specific pattern: In a directory with a sticky bit set: /zfs# mkdir testdir /zfs# chmod a+t testdir ... which is group writable: /zfs# chmod g+w testdir ... and has an existing file: /zfs# touch testdir/test ... which has a uid which isn't present on the system: /zfs# chown 9999 testdir/test ... then an open() call with O_CREAT fails with Permission denied: /zfs# ./openat testdir/test Error opening testdir/test: Permission denied (13) Skip any of those steps and it doesn't throw the error. It's just that specific configuration of directory permissions and file ownership that seems to do it. The ./openat is a simple test case that just runs open() (so named as I was originally testing with the openat() call) and it's attached for reference. We have an rsync --inplace that gets us into that specific scenario. Dropping the --inplace works around it, FWIW, but then we lose a little space within the ZFS snapshots. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1887727/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
