Re: [PATCH 3/6] io_uring: add support for IORING_OP_OPENAT

[Stefan Metzmacher <metze@samba.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2553 bytes --]

Am 08.01.20 um 23:53 schrieb Jens Axboe:
> On 1/8/20 10:04 AM, Stefan Metzmacher wrote:
>> Am 08.01.20 um 17:40 schrieb Jens Axboe:
>>> On 1/8/20 9:32 AM, Stefan Metzmacher wrote:
>>>> Am 08.01.20 um 17:20 schrieb Jens Axboe:
>>>>> On 1/8/20 6:05 AM, Stefan Metzmacher wrote:
>>>>>> Hi Jens,
>>>>>>
>>>>>>> This works just like openat(2), except it can be performed async. For
>>>>>>> the normal case of a non-blocking path lookup this will complete
>>>>>>> inline. If we have to do IO to perform the open, it'll be done from
>>>>>>> async context.
>>>>>>
>>>>>> Did you already thought about the credentials being used for the async
>>>>>> open? The application could call setuid() and similar calls to change
>>>>>> the credentials of the userspace process/threads. In order for
>>>>>> applications like samba to use this async openat, it would be required
>>>>>> to specify the credentials for each open, as we have to multiplex
>>>>>> requests from multiple user sessions in one process.
>>>>>>
>>>>>> This applies to non-fd based syscall. Also for an async connect
>>>>>> to a unix domain socket.
>>>>>>
>>>>>> Do you have comments on this?
>>>>>
>>>>> The open works like any of the other commands, it inherits the
>>>>> credentials that the ring was setup with. Same with the memory context,
>>>>> file table, etc. There's currently no way to have multiple personalities
>>>>> within a single ring.
>>>>
>>>> Ah, it's user = get_uid(current_user()); and ctx->user = user in
>>>> io_uring_create(), right?
>>>
>>> That's just for the accounting, it's the:
>>>
>>> ctx->creds = get_current_cred();
>>
>> Ok, I just looked at an old checkout.
>>
>> In kernel-dk-block/for-5.6/io_uring-vfs I see this only used in
>> the async processing. Does a non-blocking openat also use ctx->creds?
> 
> There's basically two sets here - one set is in the ring, and the other
> is the identity that the async thread (briefly) assumes if we have to go
> async. Right now they are the same thing, and hence we don't need to
> play any tricks off the system call submitting SQEs to assume any other
> identity than the one we have.

I see two cases using it io_sq_thread() and
io_wq_create()->io_worker_handle_work() call override_creds().

But aren't non-blocking syscall executed in the context of the thread
calling io_uring_enter()->io_submit_sqes()?
In only see some magic around ctx->sqo_mm for that case, but ctx->creds
doesn't seem to be used in that case. And my design would require that.

metze


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]