linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).