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:
signature.asc
Description: OpenPGP digital signature
