control: found -1 btrfs-progs/7.0-1
control: tag -1 moreinfo
Hi Russell,
Thanks for reporting, reply follows inline. I need one morsel of info before forwarding this upstream:
Russell Coker <russell@coker.com.au> writes:
[snip]
[snip]
I tested if this was a fundamental permissions handling issue rather
than a SE Linux-specific thing; this looks like an unhandled general
case to me. What is more, it's arguably a regression. Btrfs-progs 6.14 (in
Debian 13/trixie) emits the following error for EPERM EACCES on a
directory (as a normal user):
WARNING: cannot read default subvolume id: Operation not permitted
What error does btrfs-progs 6.14-1 emit in the case of an EPERM EACCESS
caused by SE Linux?
Insufficieng plain UNIX permissions fail silently in btrfs-progs >=7.0:
$ cd snapshots
$ sudo btrfs snap ../some_subvolume some_subvolume_snap
$ sudo chmod go-rwx some_subvolume_snap
$ btrfs sub delete some_subvolume_snap # silently errors
$ strace btrfs sub delete some_subvolume_snap
…
openat(AT_FDCWD, "/btrfs-admin/Red/snapshots", O_RDONLY) = 3
ioctl(3, BTRFS_IOC_TREE_SEARCH, {key={tree_id=BTRFS_ROOT_TREE_OBJECTID, min_objectid=BTRFS_ROOT_TREE_DIR_OBJECTID, max_objectid=BTRFS_ROOT_TREE_DIR_OBJECTID, min_offset=0, max_offset=UINT64_MAX, min_transid=0, max_transid=UINT64_MAX, min_type=BTRFS_DIR_ITEM_KEY, max_type=BTRFS_DIR_ITEM_KEY, nr_items=4096}}) = -1 EPERM (Operation not permitted)
geteuid() = 1000
openat(AT_FDCWD, "@some_subvolume_snap", O_RDONLY) = -1 EACCES (Permission denied)
close(3) = 0
exit_group(1) = ?
+++ exited with 1 +++
Cheers,
Nicholas