[jdk21u-dev] RFR: 8337966: (fs) Files.readAttributes fails with Operation not permitted on older docker releases [v3]

[Alexey Bakhtin]

On Fri, 6 Sep 2024 10:18:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> As mentioned in the bug it affects a rather old Docker release. Releases prior v18.4 (2019). It's been fixed in newer versions. So the question is how widespread is this? It must be systems where statx is available in the first place (kernel > 4.11 and glibc >= 2.28; systems not meeting the criteria won't use statx), but with the old docker version.

It is always curious how strange the real configurations can be. For example, the the host is an old Linux version (e.g. Ubuntu 16) with an old Docker version ( < 18.4 ) runs modern Linux with JDK17/JDK21 inside the container. It could be the only way to run JDK17/JDK21 on such a system, and everything works fine except for statx/copy_file_range syscalls.

> Someone familiar with seccomp might be able to say for sure. I think it's that the seccomp filters cause EPERM to be returned rather than the glibc or actual sys call.

It is my understanding also that EPERM for statx is caused by seccomp only, but I can not find proof in the documentation.

> With the proposed code, when running in a Docker container —or, more generically, with a seccomp filter blocking statx— each call will be penalized going through statx and stat because the unavailability of statx due to a filter is never recorded. Recording this would require handling contention.

As suggested by @bplb here https://github.com/openjdk/jdk/pull/20484#issuecomment-2312952018, we can remember if statx fails with EPERM on the first use and next time fallback to stat immediately.  
Checking seccomp profile at runtime without calling statx will require additional CAP_SYS_ADMIN privileges. So, I think it is not usable here

-------------

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/951#issuecomment-2334623179