Other user-space threading issues

[David Kahurani]

Just replying to this :
https://lwn.net/ml/all/20260911154148.644489-2-axboe@xxxxxxxxx/ but
because this thread is locked on lwn.net I will do it right here :-)

...............


I know you do ask for this and this not part of the review to the
patchset it responds to. However, I think this is important enough to
append here. At least for FYI purposes.

io-uring uses a file model and a file model, from the looks of it( not
something I have a lot of experience with), seems very leniet in it's
security model especially from a user-space perspective. For instance,
there's no way to restrict a process from reading data that belongs to
another process, if the socket is shared. This is obviously something
that is probably common across all files. In other words, a shared
file could possibly be generally said to be, insecure. I don't know
for sure.

io-uring has file_table construct and a buffer concept. These are
additional concepts to a filesystem file's private_data. At the same
time, these objects and members of io-uring will get shared when the
file is shared across processes.

The above obviously introduces additional security and possibly
*memory* concerns. If one process for instance setups up an io-uring
and add somes files into the file table, then the ring gets shared
with another process, then and now this second process has access to
the contents of the file_table and possibly files that the first
process didn't share with it. In fact, the second process can now even
close files that were opened the by first process and then saved to
the file_table. Just essentially putting, the second process now
essentially has total control over files that belong to the first
process. This and vice versa.

The same thing applies to buffers. In fact, just going with the
scenario above, whereby we have a first process and a second process
and the first process configures buffers then shares the ring. The
second process can for instance, add buffers to the head of the buffer
list and each time the first process grabs a buffer from the
buffer_list then this buffer belongs to the second process; the kernel
doesn't know this and proceeds to write to the buffer and eventually
the second process can now watch what is happening in the first
process and the first process is denied access to it's data,
effectively. This could be a bug even in a normal / ordinary consumer
operations where there's no malicious users at all.

At the very least, the above are at least issues that are mostly
fairly inconsequential and probably ill described but, still, I am yet
to come across io-uring code that works around these problem(s).

Anyways

..................