From: Tao Cui <cui.tao@linux.dev>
To: axboe@kernel.dk, rostedt@goodmis.org, mhiramat@kernel.org,
dgilbert@interlog.com, James.Bottomley@HansenPartnership.com,
mkp@kernel.org
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com, cui.tao@linux.dev,
Tao Cui <cuitao@kylinos.cn>
Subject: [PATCH v2 0/2] blktrace: gate the blktrace interface behind CAP_SYS_ADMIN
Date: Wed, 11 Nov 2026 22:50:32 +0800 [thread overview]
Message-ID: <20261111145034.248717-1-cui.tao@linux.dev> (raw)
From: Tao Cui <cuitao@kylinos.cn>
hello,
This series gates the blktrace interface behind CAP_SYS_ADMIN.
BLKTRACESETUP allocates user-sized relay buffers and sets up traces
that outlive the creating fd, but holding the block device node, an
sg node, or write access to the sysfs trace attributes is the only
requirement to drive that state today. Split by tree so each patch
stays in one subsystem: patch 1 gates the block side (the ioctl
dispatch and the sysfs store) and documents the sysfs attributes,
patch 2 gates the sg passthrough. The two are independent and can
be applied in any order; patch 1 should go through the block tree,
patch 2 needs a SCSI Ack (taking both through block with the Ack
works too).
Unprivileged callers get a single answer (-EPERM for the ioctls,
-EACCES for the sysfs store) instead of values that revealed whether
a trace existed and was running. With CONFIG_BLK_DEV_IO_TRACE=n the
sg passthrough still returns -ENOTTY, as before. Privileged callers
behave identically with and without the series.
Verified on next-20261104 under qemu: with the series applied,
BLKTRACESETUP with all capabilities dropped is rejected with -EPERM
through both /dev/sda and /dev/sg0, and a dropped-privilege write to
the sysfs enable attribute is rejected with -EACCES; without the
series the unprivileged ioctl and the sysfs write both succeed.
Base: next-20261104.
Changes since v1:
- also gate the sysfs trace attribute group, which reached the same
tracing state without any check (found in follow-up review)
- document the sysfs trace group in Documentation/ABI, where it has
been missing since 2009
- gate the sg passthrough commands in a new patch; the v1 commit
message mentioned the sg path but gated only blk_trace_ioctl()
(flagged by sashiko's review of the first posting)
- commit messages now claim only what each patch covers
Link: https://lore.kernel.org/all/20261106142852.3233950-1-cui.tao@linux.dev/
Tao Cui (2):
blktrace: require CAP_SYS_ADMIN for the blktrace interface
scsi: sg: Require CAP_SYS_ADMIN for BLKTRACE passthrough ioctls
Documentation/ABI/stable/sysfs-block | 18 ++++++++++++++++++
drivers/scsi/sg.c | 10 ++++++++++
kernel/trace/blktrace.c | 6 ++++++
3 files changed, 34 insertions(+)
--
2.53.0
next reply other threads:[~2026-11-11 14:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 14:50 Tao Cui [this message]
2026-11-11 14:50 ` [PATCH v2 1/2] blktrace: require CAP_SYS_ADMIN for the blktrace interface Tao Cui
2026-11-11 14:50 ` [PATCH v2 2/2] scsi: sg: Require CAP_SYS_ADMIN for BLKTRACE passthrough ioctls Tao Cui
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=20261111145034.248717-1-cui.tao@linux.dev \
--to=cui.tao@linux.dev \
--cc=James.Bottomley@HansenPartnership.com \
--cc=axboe@kernel.dk \
--cc=cuitao@kylinos.cn \
--cc=dgilbert@interlog.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mkp@kernel.org \
--cc=rostedt@goodmis.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
all inboxes | Powered by JetHome®