From: "Holger Hoffstätte" <holger@applied-asynchrony.com>
To: Hans van Kranenburg <Hans.van.Kranenburg@mendix.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Curious problem: btrfs device stats & unpriviliged access
Date: Mon, 8 Oct 2018 17:29:37 +0200 [thread overview]
Message-ID: <7bcc7f99-a857-6ef1-d2df-a256424d2b29@applied-asynchrony.com> (raw)
In-Reply-To: <5eafba35-c79b-17f2-e296-aafddf06ebf1@mendix.com>
On 10/08/18 16:40, Hans van Kranenburg wrote:
>> Looking at the kernel side of things in fs/btrfs/ioctl.c I see both
>> BTRFS_IOC_TREE_SEARCH[_V2} unconditionally require CAP_SYS_ADMIN.
>
> That's the tree search ioctl, for reading arbitrary metadata.
>
> The device stats ioctl is IOC_GET_DEV_STATS...
Yeah..OK, that is clear and gave me the hint to ask: why is it
calling this in the first place? And as it turns out [1] is where
it seems to go wrong, as is_block_device() returns 0 (as it should),
fi_args.num_devices is never set (remains 0) and it proceeds to call
everything below, eventually calling the BTRFS_IOC_FS_INFO ioctl in
#1712. And that works fine:
1711 if (fi_args->num_devices != 1) {
(gdb) s
1712 ret = ioctl(fd, BTRFS_IOC_FS_INFO, fi_args);
(gdb) s
1713 if (ret < 0) {
(gdb) p ret
$28 = 0
(gdb) p *fi_args
$30 = {
max_id = 1,
num_devices = 1,
fsid = "z%:\371\315\033A\203\267.\200\255;FH\221",
nodesize = 16384,
sectorsize = 4096,
clone_alignment = 4096,
reserved32 = 0,
reserved = {0 <repeats 122 times>}
}
It's only when it goes into search_chunk_tree_for_fs_info()
where things fail due to CAP_SYS_ADMIN.
And all this explains the actual bug: when I call btrfs device stats
not on the mountpoint (as I've been trying all this time) but rather
on the device, it works properly right away as regular user:
(gdb) set args device stats /dev/loop0
(gdb) r
Breakpoint 1, get_fs_info (path=path@entry=0x7fffffffe527 "/dev/loop0", fi_args=fi_args@entry=0x7fffffffd400,
di_ret=di_ret@entry=0x7fffffffd3f0) at utils.c:1652
1652 {
(gdb) c
Continuing.
[/dev/loop0].write_io_errs 0
[/dev/loop0].read_io_errs 0
[/dev/loop0].flush_io_errs 0
[/dev/loop0].corruption_errs 0
[/dev/loop0].generation_errs 0
[Inferior 1 (process 2805) exited normally]
So this is simply a discrepancy in handling a device vs. the device(s)
for a mountpoint.
> I can do the device stats ioctl as normal user:
>
> import btrfs
> fs = btrfs.FileSystem('/')
> btrfs.utils.pretty_print(fs.dev_stats(1))
>
> <btrfs.ioctl.DevStats>
> devid: 1
> nr_items: 5
> flags: 0
> write_errs: 0
> read_errs: 0
> flush_errs: 0
> generation_errs: 0
> corruption_errs: 0
That works for me too, and that's actually the important part. \o/
Glad we talked about it. :}
-h
[1] https://github.com/kdave/btrfs-progs/blob/7faaca0d9f78f7162ae603231f693dd8e1af2a41/utils.c#L1666
next prev parent reply other threads:[~2018-10-08 15:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-08 14:27 Curious problem: btrfs device stats & unpriviliged access Holger Hoffstätte
2018-10-08 14:40 ` Hans van Kranenburg
2018-10-08 14:54 ` Hans van Kranenburg
2018-10-08 15:29 ` Holger Hoffstätte [this message]
2018-10-08 15:46 ` Hans van Kranenburg
2018-10-08 16:37 ` Holger Hoffstätte
2018-10-08 20:02 ` Hans van Kranenburg
2019-10-23 14:24 ` Holger Hoffstätte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7bcc7f99-a857-6ef1-d2df-a256424d2b29@applied-asynchrony.com \
--to=holger@applied-asynchrony.com \
--cc=Hans.van.Kranenburg@mendix.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).