linux-kernel - Re: [External] Re: [PATCH 0/5] io_uring: add opcodes for current working directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d466213e-81e0-4b0e-c1a4-824bcbe42f74@kernel.dk>
Date:   Tue, 31 May 2022 13:22:49 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Usama Arif <usama.arif@...edance.com>, io-uring@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     fam.zheng@...edance.com
Subject: Re: [External] Re: [PATCH 0/5] io_uring: add opcodes for current
 working directory

On 5/31/22 1:18 PM, Usama Arif wrote:
> 
> 
> On 31/05/2022 19:58, Jens Axboe wrote:
>> On 5/31/22 12:41 PM, Usama Arif wrote:
>>> This provides consistency between io_uring and the respective I/O syscall
>>> and avoids having the user of liburing specify the cwd in sqe when working
>>> with current working directory, for e.g. the user can directly call with
>>> IORING_OP_RENAME instead of IORING_OP_RENAMEAT and providing AT_FDCWD in
>>> sqe->fd and sqe->len, similar to syscall interface.
>>>
>>> This is done for rename, unlink, mkdir, symlink and link in this
>>> patch-series.
>>>
>>> The tests for these opcodes in liburing are present at
>>> https://github.com/uarif1/liburing/tree/cwd_opcodes. If the patches are
>>> acceptable, I am happy to create a PR in above for the tests.
>>
>> Can't we just provide prep helpers for them in liburing?
>>
> 
> We could add a io_uring_prep_unlink with IORING_OP_UNLINKAT and
> AT_FDCWD in liburing. But i guess adding in kernel adds a more
> consistent interface? and allows to make calls bypassing liburing
> (although i guess people probably don't bypass liburing that much :))

I'm not really aware of much that doesn't use the library, and even
those would most likely use the liburing man pages as that's all we
have. The kernel API is raw. If you use that, I would expect you to know
that you can just use AT_FDCWD!

> Making the changes in both kernel and liburing provides more of a
> standard interface in my opinion so maybe it looks better. But happy
> to just create a PR in liburing only with prep helpers as you
> suggested if you think that is better?

I don't disagree with that, but it seems silly to waste 5 opcodes on
something that is a strict subset of something that is already there.
Hence my suggestion would be to just add io_uring_prep_link() etc
helpers to make it simpler to use, without having to add 5 extra
opcodes.

-- 
Jens Axboe