On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl <d...@openjdk.org> wrote:
>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid >> (Kubernetes debug container) > > 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__;!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbLIEsaUnQ$>. > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------XQdcZo9hO6wbcp2fGsjP1B9A Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Hi Sebastian!<br> <br> <div class="moz-cite-prefix">On 5/21/24 9:50 AM, Sebastian Lövdahl wrote:<br> </div> <blockquote type="cite" ***@***.***"> <blockquote> <p dir="auto">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. </p> </blockquote> </blockquote> <br> 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<br> appropriate +og r/w access then it will be successful.<br> <br> the "root" requirement comes from the default behavior of the container mgmt (docker) running containers as 'root'.<br> <br> 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<br> <br> note: if the container is in a distinct uid ns (from the attacher) I think the current checks performed by <font face="Courier New, Courier, monospace"><b>os::Posix::matches_effective_uid_and_gid_or_root</b></font> 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!)<br> <br> <blockquote type="cite" ***@***.***"> <blockquote> <p dir="auto">Or is there some way to attach from host to container with a non-root user that I'm missing?</p> </blockquote> <p dir="auto">Or could it work in case the container is also run as a non-<code class="notranslate">root</code> user?</p> </blockquote> <br> 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<br> to /tmp will not work and since the attacher and the attachee do not share a fs...<br> <br> 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<br> 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...<br> <br> Rgds<br> <br> - Larry<br> <br> <blockquote type="cite" ***@***.***"> <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br> Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2123042958__;Iw!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbKzJlBhjQ$"; moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67XPE34N46VDFUEMSHDZDN3NHAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGA2DEOJVHA__;!!ACWV5N9M2RV99hQ!NbYaR1TB-qDG-x11SE_XRwyQgFwVKEPiL9gmrrFqxio1p2TAsJmsyBKhvICqMROIcMGpC8U7jfjenhr5WbLIEsaUnQ$"; moz-do-not-send="true">unsubscribe</a>.<br> You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67Q4FA2GDVB3NAFU5I3ZDN3NHA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6RMII4.gif"; alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openjdk/jdk/pull/19055/c2123042958</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p> <script type="application/ld+json">[ { ***@***.***": "http://schema.org";, ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2123042958";, "url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2123042958";, "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com"; } } ]</script> </blockquote> <br> </body> </html> --------------XQdcZo9hO6wbcp2fGsjP1B9A-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2123442646
![https://github.com/notifications/beacon/ANTA67Q4FA2GDVB3NAFU5I3ZDN3NHA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6RMII4.gif"](https://github.com/notifications/beacon/ANTA67Q4FA2GDVB3NAFU5I3ZDN3NHA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6RMII4.gif"){kind=link}