On Tue, 21 May 2024 21:06:22 GMT, Larry Cable <d...@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
