From: Kanchan Joshi <joshi.k@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org
Subject: Re: block dangerous passthrough operation
Date: Thu, 17 Nov 2022 08:43:36 +0530 [thread overview]
Message-ID: <20221117031336.GA392@test-zns> (raw)
In-Reply-To: <20221116154415.GA18491@lst.de>
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
On Wed, Nov 16, 2022 at 04:44:15PM +0100, Christoph Hellwig wrote:
>On Wed, Nov 16, 2022 at 07:13:22PM +0530, Kanchan Joshi wrote:
>> I see, good to know. I am still missing something.
>> This series is on top of nvme-6.2, since nvme_cmd_allowed did not exist
>> earlier.
>> In that case having this series or not having - gives the same effect,
>> no?
>
>Yes, no change due to the series introducing nvme_cmd_allowed.
>It is just a convenient place to put the checks.
Got it now. The series is about restricting root/admin itself from doing
certain things.
If we end up going this route, putting a new helper seems clearer to me.
Something like this:
if (capable(CAP_SYS_ADMIN)) {
return admin_only_checks();
}
/* regular user checks as before */
But if there are people using the upstream driver for testing
nvme-hardware, restricting may not go well. Stuff like creating SQ/CQ
in early stages of new SSD/controller development may just be
the thing they want to test.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2022-11-17 3:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20221116130636epcas5p39a586e15d27045752f18d022f4efd74a@epcas5p3.samsung.com>
2022-11-16 13:01 ` block dangerous passthrough operation Christoph Hellwig
2022-11-16 13:01 ` [PATCH 1/4] nvme: return an errno from nvme_cmd_allowed Christoph Hellwig
2022-11-16 13:01 ` [PATCH 2/4] nvme: don't allow user space to send fabrics commands Christoph Hellwig
2022-11-16 13:01 ` [PATCH 3/4] nvme: don't allow userspace to set the Host Behavior Support feature Christoph Hellwig
2022-11-16 13:01 ` [PATCH 4/4] nvme: reject passthrough of queue creation / deletion commands Christoph Hellwig
2022-11-16 13:25 ` block dangerous passthrough operation Kanchan Joshi
2022-11-16 13:38 ` Christoph Hellwig
2022-11-16 13:43 ` Kanchan Joshi
2022-11-16 15:44 ` Christoph Hellwig
2022-11-17 3:13 ` Kanchan Joshi [this message]
2022-11-21 7:43 ` Christoph Hellwig
2022-11-16 16:12 ` Keith Busch
2022-11-17 3:51 ` Kanchan Joshi
2022-11-17 16:03 ` Keith Busch
2022-11-17 6:48 ` Chaitanya Kulkarni
2022-11-21 7:45 ` Christoph Hellwig
2022-11-17 3:49 ` Jens Axboe
2022-11-21 7:46 ` Christoph Hellwig
2022-11-21 15:35 ` Keith Busch
2022-11-22 6:47 ` Christoph Hellwig
2022-11-22 10:38 ` Sagi Grimberg
2022-11-22 12:03 ` Christoph Hellwig
2022-11-22 15:11 ` Keith Busch
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=20221117031336.GA392@test-zns \
--to=joshi.k@samsung.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.