RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container) [v3]

[Sebastian Lövdahl]

On Tue, 21 May 2024 21:06:22 GMT, Larry Cable <duke at openjdk.org> wrote:

>> Sebastian Lövdahl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove unused `SELF_PID_NS`
>>  - Rewrite in line with suggestion from Larry Cable
>
> Hi Sebastian!
> 
> On 5/21/24 9:50 AM, Sebastian Lövdahl wrote:
>>
>>     In these cases, is it not a requirement that jcmd is run as root?
>>     So even if the target process is run with elevated privileges,
>>     attaching would always work.
>>
> 
> the constraint (as I understand it) is based upon the filesystem access 
> to /proc/<attachee>/root/tmp, where the createAttachFile fails... if the 
> "attacher" (jcmd) has access, if it has the
> appropriate +og r/w access then it will be successful.
> 
> the "root" requirement comes from the default behavior of the container 
> mgmt (docker) running containers as 'root'.
> 
> if you employ the --user option to 'force' the container to adopt a 
> non-root identity jcmd will succeed if issued from the same 
> user&group... because it has r/w access to the /proc/<attachee>/root/tmp
> 
> note: if the container is in a distinct uid ns (from the attacher) I 
> think the current checks performed by 
> *os::Posix::matches_effective_uid_and_gid_or_root* will complete since 
> the comparison is based on the uid values returned by the O.S 
> (independent of the fact that the uid's may exist in distinct uid ns'es!)
> 
>>     Or is there some way to attach from host to container with a
>>     non-root user that I'm missing?
>>
>> Or could it work in case the container is also run as a non-|root| user?
>>
> 
> the use case I was addressing with my proposal is when the jcmd 
> "container" (as a sidecar) is in the same pid ns as the target container 
> but in a different mnt ns (I believe this is the regression use case) in 
> that case falling back
> to /tmp will not work and since the attacher and the attachee do not 
> share a fs...
> 
> if the target JVM has elevated privs a (sidecar) attacher cannot use the 
> target's /proc/<attachee>/root/... hence my experiment to recurse "up" 
> the attachee's pid ns to look for a an un-privileged ancestor, which does
> share the same mnt ns as the attachee, so the attacher can use the 
> /proc/<ancestor>/root/tmp to attach to the target... all things being 
> equal...
> 
> Rgds
> 
> - Larry
> 
>> —
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2123042958__;Iw!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbKzJlBhjQ$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67XPE34N46VDFUEMSHDZDN3NHAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGA2DEOJVHA__;!!AC...

Thanks for the explanation @larry-cable, that makes sense. By chance, did you already test the Docker `--user` case with the suggested patch? I don't have access to an environment with rootless Docker at hand, but I may be able to set it up in a VM if you didn't already test it.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2124324590