RFR: 8226919: attach in linux hangs due to permission denied accessing /proc/pid/root

Kevin Walls kevinw at openjdk.org
Thu Feb 29 15:21:57 UTC 2024


On Wed, 28 Feb 2024 20:02:39 GMT, jdoylei <duke at openjdk.org> wrote:

> If I understand the code change for this PR, I think it will change the behavior in this scenario, because `findSocketFile` will have `pid == ns_pid`, and now will use /tmp instead of `/proc/<pid>/root/tmp`, based on `findTargetProcessTmpDirectory`.
> 
> We are lucky currently that the only place the current OpenJDK 17 code checks `pid == ns_pid` is the `createAttachFile` catch block that runs if `/proc/<pid>/cwd/.attach_pid<ns_pid>` can't be created, since as long as `/proc/<pid>/cwd` works, we are fine. But the `pid != ns_pid` check there makes an assumption that if the process namespace is the same, the root filesystem is the same and /tmp can be used, so this catch block wouldn't work if we were to hit it in our scenario. I think propagating this catch block logic into `findSocketFile` will break our scenario - it will force using `/tmp/.java_pid<ns_pid>` and that won't work.
> 
> Could the `findSocketFile` logic be made more robust to the different namespace/filesystem scenarios? E.g. attempt `/proc/<pid>/root` first? Or perhaps there is a way (not `pid != ns_pid`) to more accurately determine whether / and `/proc/<pid>/root` are the same filesystem and /tmp is OK?

That is certainly worth capturing in a new JBS bug for investigating a further change.  If you can't log one, I'll use the information here to do that, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1971364928


More information about the serviceability-dev mailing list