How to allow io_uring?

[apupier]

I read #16796 on this topic which is suggesting as one option (and the one I think i will be to use in the context of TestContainer) to deactivate seccomp with --security-opt seccomp=unconfined

When i try that, the error is slightly different but it is still not working:

> podman run -e RUST_BACKTRACE=full apache/iggy:0.6.0

thread 'main' (1) panicked at core/server/src/main.rs:74:13:
Cannot create runtime: Function not implemented (os error 38)
stack backtrace:
   0:          0x1cd8892 - <unknown>
   1:          0x14dc44f - <unknown>
   2:          0x1cd835f - <unknown>
   3:          0x1cd86f3 - <unknown>
   4:          0x1cd7d71 - <unknown>
   5:          0x1d013b8 - <unknown>
   6:          0x1d01319 - <unknown>
   7:          0x1d0130c - <unknown>
   8:          0x14d7eff - <unknown>
   9:          0x1310206 - <unknown>
  10:          0x133dac3 - <unknown>
  11:          0x142588d - <unknown>

podman run --security-opt seccomp=unconfined -e RUST_BACKTRACE=full apache/iggy:0.6.0

=== io_uring Permission Denied ===

The io_uring runtime requires specific syscalls that are blocked by default
in containerized environments (Docker, Podman, etc.).

To resolve this issue:

  1. Docker Compose (add to service):
     security_opt:
       - seccomp:unconfined

  2. Docker run:
     docker run --security-opt seccomp=unconfined ...

  3. Custom seccomp profile (more secure):
     Create a profile allowing io_uring_setup, io_uring_enter,
     and io_uring_register syscalls.

  4. Kubernetes (add to pod spec):
     securityContext:
       seccompProfile:
         type: Unconfined


thread 'main' (1) panicked at core/server/src/main.rs:74:13:
Cannot create runtime: Permission denied (os error 13)
stack backtrace:
   0:          0x1cd8892 - <unknown>
   1:          0x14dc44f - <unknown>
   2:          0x1cd835f - <unknown>
   3:          0x1cd86f3 - <unknown>
   4:          0x1cd7d71 - <unknown>
   5:          0x1d013b8 - <unknown>
   6:          0x1d01319 - <unknown>
   7:          0x1d0130c - <unknown>
   8:          0x14d7eff - <unknown>
   9:          0x1310206 - <unknown>
  10:          0x133dac3 - <unknown>
  11:          0x142588d - <unknown>

Any ideas how I can configure it correctly?

Regards,

[nalind]

Are you by any chance running on a system with some type of mandatory access control enabled? When I try this on a Fedora 43 system with SELinux enabled, I get the same error message, and this denial in my audit log:

type=AVC msg=audit(1767724951.807:959): avc:  denied  { create } for  pid=2902201 comm="iggy-server" anonclass=[io_uring] scontext=system_u:system_r:container_t:s0:c758,c910 tcontext=system_u:object_r:io_uring_t:s0:c758,c910 tclass=anon_inode permissive=0

If I temporarily switch SELinux to permissive mode, the container appears to start up without complaints.

[http403]

I'm having the same problem with vLLM on Fedora 42, but not as catastrophic. It just soft fail instead of a hard crash. Switching SELinux to permissive does solve the problem but it defeats the purpose of using SELinux.