Risks from usage of CHROOT inside a Docker container

Risks from usage of CHROOT inside a Docker container

Can --cap-add SYS_CHROOT on a docker container be questioned as a potential security risk, and why?

I'm seeking references and information from security professionals about using the chroot tool (and the SYS_CHROOT Linux capability) inside a docker container.

(background) I'm developing an application to run inside a Docker container; the application receives requests from various users; each request is allocated a working directory with files and requires a third-party command line tool; isolation of users and requests must be guaranteed. Specifically, a threat actor may submit a request that tries to read or override files of other users or previous requests; this may seem like a matter of fundamental path validation, but it's not: the third-party tool can be trusted, but its user-provided configuration is complex, cannot be analyzed by my application, cannot be trusted and cannot be validated either. There may be other risks, but I'm focused on isolating the working directory allocated to the request. Then chroot would be perfect, as the assigned working directory would be my fake root.

I may be confused by various sources I've found telling me that:

1. A compromised application may use techniques to escape a chroot jail, so if this risk has to be considered authentic, then chroot may not be regarded as an appropriate and secure solution.
2. There is news about Unprivileged chroot: a patch on recent kernel versions that may make Chroot safe against previous escape techniques (and available to unprivileged users, without SYS_CHROOT), invalidating the above point (1).
3. The same news from above discusses the patch and says that chroot is obsolete, so the patch may even be rejected, reverted in future versions, or adopted with differences depending on the Linux distribution (e.g., Debian vs. others).
4. Some users and blog posts tell me that to use chroot inside a docker container, I need to specify --cap-add SYS_CHROOT...
5. The docker documentation says that the SYS_CHROOT capability is granted by default (maybe only from recent versions after the above patch). I can use chroot from a Debian Docker without any --cap-add.
6. A blog post suggesting to explicitly drop the SYS_CHROOT capability for better security.

For sure, any solution is better than having no isolation method. Still, it looks like adopting and configuring my system to allow me to use chroot may decrease the whole system's security.