> The security credentials of an io_uring are established at creation time. Well, the security credentials of a file descriptor are established at ```open()```

> The security credentials of an io_uring are established at creation time. Well, the security credentials of a file descriptor are established at ```open()``` time. Is this really so different? Running through the list of io_uring opcodes, only two of them work on ```char*``` paths: IORING_OP_OPENAT and IORING_OP_OPENAT2, which were added to io_uring after it was introduced. All the rest operate solely upon already-opened file descriptors, and POSIX doesn't do any permission checks for operations on already-open descriptors anyways. It sounds like the issue you mention was an oversight when IORING_OP_OPENAT(2) were added. The easy, and retroactively safe, fix is to forbid these opcodes on submission queues by default, unless the submission queue was opened with a special flag whose name includes a scary warning -- something like IOURING_I_WILL_NOT_SETUID_WITHOUT_CLOSING_THIS_RING_FIRST. https://unixism.net/loti/ref-iouring/io_uring_enter.html https://unixism.net/loti/ref-iouring/io_uring_enter.html