Public bug reported:
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.
** Affects: zfs-linux (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "Test case"
https://bugs.launchpad.net/bugs/1887727/+attachment/5393017/+files/openat.c
--
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 : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
