[libcxx][utils] Note read only mount and ptrace permission in container script

[DavidSpickett]

Thanks for the scripts and dockerfile btw, very easy to use bar these 2 details.

[ldionne]

Is the mount really read-only? I'm pretty sure I can modify files from within the Docker image and vice-versa, and everything works. Am I misunderstanding what you mean by read-only mounted?

Also, is there a reason to not always pass --cap-add=SYS_PTRACE?

Requesting changes so it shows up in my review queue.

[DavidSpickett]

Add ptrace cap always.

You were right it's not docker that's making the mount read only,
it's that the user in the container doesn't have permissions to
write to the folder in general.

I don't expect being a different user would change a CI result
too much but it would change paths and that can be noise if you're trying
to match up logs.

So added a note for a couple of ways you can fix that if you need
r/w from inside the container.

For what I was doing I just went to /tmp and did the build there,
it's not like you can't write anywhere at all.

[ldionne]

libcxx/utils/ci/run-buildbot-container

16–20

This actually doesn't match my experience. I'm able to modify the mount from within the docker container, and the user that created the monorepo on my mac (ldionne) isn't called libcxx-builder. I'm a bit confused. Is it possible that this is only on Linux?

I don't have push back against this change, except I would like to make sure the comment above is accurate.

[ldionne]

Accepting but I would like to get to the bottom of the situation if we add the comment about r/w permissions!

[DavidSpickett]

You're right the volume permissions are different for Linux vs Mac.
(probably Mac and Windows but I haven't tried Windows)

The legacy mode of docker for Mac uses osxfs:

All processes in containers can access the same objects in the same way as the Docker user who started the containers.

https://docker-docs.netlify.app/docker-for-mac/osxfs/

Couldn't find any docs on the gRPC FUSE that it uses now but I assume it would behave
the same way for compatibility reasons.

libcxx/utils/ci/run-buildbot-container

 #!/usr/bin/env bash
 
 # This script starts a shell in a container running the libc++ build bot Docker
 # image. That image emulates the environment used by libc++'s Linux builders on
 # BuildKite.
 #
 # Once you're inside the shell, you can run the various build jobs with the
 # `run-buildbot` script.
 #
 # This script must be run from within the LLVM monorepo. Furthermore, the
 # monorepo will be mounted as `/llvm` inside the container. Be careful, the
 # state in `/llvm` is shared between the container and the host machine, which
 # is useful for editing files on the host machine and re-running the build bot
 # in the container.
+#
+# If you are on Linux you will likely not be able to write to the mount because
+# the user in the container doesn't have permissions to do so.
+# If you need to do this, give that user permission to do so after running
+# the container or add this flag to run the container as your local user IDs:
+# --user $(id -u):$(id -g)
 
 set -e
 
 MONOREPO_ROOT="$(git rev-parse --show-toplevel)"
 if [[ ! -d "${MONOREPO_ROOT}/libcxx/utils/ci" ]]; then
     echo "Was unable to find the root of the LLVM monorepo; are you running from within the monorepo?"
     exit 1
 fi
 docker pull ldionne/libcxx-builder
-docker run -it --volume "${MONOREPO_ROOT}:/llvm" --workdir "/llvm" ldionne/libcxx-builder bash
+docker run -it --volume "${MONOREPO_ROOT}:/llvm" --workdir "/llvm" --cap-add=SYS_PTRACE ldionne/libcxx-builder bash