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

Tue May 21 21:09:02 UTC 2024

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl <duke at 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