All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Stefan Metzmacher <metze@samba.org>, io-uring@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCH 3/6] io_uring: add support for IORING_OP_OPENAT
Date: Thu, 16 Jan 2020 17:16:43 -0700	[thread overview]
Message-ID: <38c19d02-ff10-c4a3-3d25-c59530ada19e@kernel.dk> (raw)
In-Reply-To: <7a91c0ee-ee1c-bec4-98fd-a25664839423@samba.org>

On 1/16/20 3:42 PM, Stefan Metzmacher wrote:
>>> I'm not sure if current->mm is needed, I just added it for completeness
>>> and as hint that io_op_defs[req->opcode].needs_mm is there and a
>>> needs_creds could also be added (if it helps with performance)
>>>
>>> Is it possible to trigger a change of current->mm from userspace?
>>>
>>> An IORING_REGISTER_CREDS would only be useful if it's possible to
>>> register a set of credentials and then use per io_uring_sqe credentials.
>>> That would also be fine for me, but I'm not sure it's needed for now.
>>
>> I think it'd be a cleaner way of doing the same thing as your patch
>> does. It seems a little odd to do this by default (having the ring
>> change personalities depending on who's using it), but from an opt-in
>> point of view, I think it makes more sense.
>>
>> That would make the IORING_REGISTER_ call something like
>> IORING_REGISTER_ADOPT_OWNER or something like that, meaning that the
>> ring would just assume the identify of the task that's calling
>> io_uring_enter().
>>
>> Note that this also has to be passed through to the io-wq handler, as
>> the mappings there are currently static as well.
> 
> What's the next step here?

Not sure, need to find some time to work on this!

> I think the current state is a security problem!
> 
> The inline execution either needs to change the creds temporary
> or io_uring_enter() needs a general check that the current creds match
> the creds of the ring and return -EPERM or something similar.

Hmm, if you transfer the fd to someone else, you also give them access
to your credentials etc. We could make that -EPERM, if the owner of the
ring isn't the one invoking the submit. But that doesn't really help the
SQPOLL case, which simply consumes SQE entries. There can be no checking
there.

-- 
Jens Axboe


  reply	other threads:[~2020-01-17  0:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 17:00 [PATCHSET v2 0/6] io_uring: add support for open/close Jens Axboe
2020-01-07 17:00 ` [PATCH 1/6] fs: add namei support for doing a non-blocking path lookup Jens Axboe
2020-01-25 13:15   ` Jeff Layton
2020-01-07 17:00 ` [PATCH 2/6] fs: make build_open_flags() available internally Jens Axboe
2020-01-07 17:00 ` [PATCH 3/6] io_uring: add support for IORING_OP_OPENAT Jens Axboe
2020-01-08 13:05   ` Stefan Metzmacher
2020-01-08 16:20     ` Jens Axboe
2020-01-08 16:32       ` Stefan Metzmacher
2020-01-08 16:40         ` Jens Axboe
2020-01-08 17:04           ` Stefan Metzmacher
2020-01-08 22:53             ` Jens Axboe
2020-01-08 23:03               ` Stefan Metzmacher
2020-01-08 23:05                 ` Jens Axboe
2020-01-08 23:11                   ` Stefan Metzmacher
2020-01-08 23:22                     ` Jens Axboe
2020-01-09 10:40                       ` Stefan Metzmacher
2020-01-09 21:31                         ` Jens Axboe
2020-01-16 22:42                           ` Stefan Metzmacher
2020-01-17  0:16                             ` Jens Axboe [this message]
2020-01-07 17:00 ` [PATCH 4/6] fs: move filp_close() outside of __close_fd_get_file() Jens Axboe
2020-01-07 17:00 ` [PATCH 5/6] io-wq: add support for uncancellable work Jens Axboe
2020-01-07 17:00 ` [PATCH 6/6] io_uring: add support for IORING_OP_CLOSE Jens Axboe
2020-01-08 21:17 ` [PATCHSET v2 0/6] io_uring: add support for open/close Stefan Metzmacher
2020-01-08 22:57   ` Jens Axboe
2020-01-08 23:05     ` Stefan Metzmacher
2020-01-09  1:02       ` Jens Axboe
2020-01-09  2:03         ` Jens Axboe
2020-01-16 22:50           ` Stefan Metzmacher
2020-01-17  0:18             ` Jens Axboe
2020-01-20 12:15               ` Stefan Metzmacher
2020-01-20 13:04                 ` Pavel Begunkov
2020-01-17  0:44             ` Colin Walters
2020-01-17  0:51               ` Jens Axboe
2020-01-17  9:32               ` Pavel Begunkov
2020-01-17 15:21                 ` Jens Axboe
2020-01-17 22:27                   ` Pavel Begunkov
2020-01-17 22:36                     ` Jens Axboe

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=38c19d02-ff10-c4a3-3d25-c59530ada19e@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=metze@samba.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.