linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Thoughts on 'btrfs device stats' and security.
Date: Fri, 17 Mar 2017 12:01:50 -0700	[thread overview]
Message-ID: <feb89fc0-e7c6-53f5-5eaf-222b7a7a05b7@redhat.com> (raw)
In-Reply-To: <f0bd54bf-930b-c489-8bd3-e3b5a4cc965e@gmail.com>

On 3/17/17 11:25 AM, Austin S. Hemmelgarn wrote:
> I'm currently working on a plugin for colllectd [1] to track per-device per-filesystem error rates for BTRFS volumes.  Overall, this is actually going quite well (I've got most of the secondary logic like matching filesystems to watch and parsing the data done already), but I've come across a rather nasty caveat on the actual data collection part.
> 
> As of right now, there are only two ways I can see to get this data:
> 1. Parse the output of `btrfs device stats` for the filesystem.
> 2. Make the same ioctl() call that `btrfs device stats` does and compose the data yourself.
> 
> In both cases, one of the following has to be the case:
> 1. You're running as root.
> 2. You're running SUID root.
> 3. You're running with CAP_SYS_ADMIN (I'm not 100% certain that this is the correct capability, but it appears to be the case from my testing).
> 
> In other words, you have to reduce the overall security of your system to be able to get this data which is itself not security sensitive for most intents and purposes.

As one datapoint, xfs stats are ugo+r -

see /proc/fs/xfs/stat or /sys/fs/xfs/<device>/stats/stats

-r--r--r--. 1 root root 4096 Mar 17 13:58 stats

However, the stats_clear file is only writable by root

--w-------. 1 root root 4096 Mar 17 13:58 stats_clear

Stats & other info for ext4 are also ugo+r, other than
an error trigger which is only writable by root, and
for which a read is meaningless.

/sys/fs/ext4/sda1/

-r--r--r--. 1 root root 4096 Mar 17 14:00 delayed_allocation_blocks
-r--r--r--. 1 root root 4096 Mar 17 14:00 errors_count
-rw-r--r--. 1 root root 4096 Mar 17 14:00 err_ratelimit_burst
-rw-r--r--. 1 root root 4096 Mar 17 14:00 err_ratelimit_interval_ms
-rw-r--r--. 1 root root 4096 Mar 17 14:00 extent_max_zeroout_kb
-r--r--r--. 1 root root 4096 Mar 17 14:00 first_error_time
-rw-r--r--. 1 root root 4096 Mar 17 14:00 inode_goal
-rw-r--r--. 1 root root 4096 Mar 17 14:00 inode_readahead_blks
-r--r--r--. 1 root root 4096 Mar 17 14:00 last_error_time
-r--r--r--. 1 root root 4096 Mar 17 14:00 lifetime_write_kbytes
-r--r--r--. 1 root root 4096 Mar 17 14:00 max_writeback_mb_bump
-rw-r--r--. 1 root root 4096 Mar 17 14:00 mb_group_prealloc
-rw-r--r--. 1 root root 4096 Mar 17 14:00 mb_max_to_scan
-rw-r--r--. 1 root root 4096 Mar 17 14:00 mb_min_to_scan
-rw-r--r--. 1 root root 4096 Mar 17 14:00 mb_order2_req
-rw-r--r--. 1 root root 4096 Mar 17 14:00 mb_stats
-rw-r--r--. 1 root root 4096 Mar 17 14:00 mb_stream_req
-rw-r--r--. 1 root root 4096 Mar 17 14:00 msg_ratelimit_burst
-rw-r--r--. 1 root root 4096 Mar 17 14:00 msg_ratelimit_interval_ms
-rw-r--r--. 1 root root 4096 Mar 17 14:00 reserved_clusters
-r--r--r--. 1 root root 4096 Mar 17 14:00 session_write_kbytes
--w-------. 1 root root 4096 Mar 17 14:00 trigger_fs_error
-rw-r--r--. 1 root root 4096 Mar 17 14:00 warning_ratelimit_burst
-rw-r--r--. 1 root root 4096 Mar 17 14:00 warning_ratelimit_interval_ms


-Eric

  reply	other threads:[~2017-03-17 19:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17 18:25 Thoughts on 'btrfs device stats' and security Austin S. Hemmelgarn
2017-03-17 19:01 ` Eric Sandeen [this message]
2017-03-17 19:45   ` Austin S. Hemmelgarn

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=feb89fc0-e7c6-53f5-5eaf-222b7a7a05b7@redhat.com \
    --to=sandeen@redhat.com \
    --cc=ahferroin7@gmail.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).