fix(LWLP-1476): make cargo home group-writable for OCP non-root conta…

[Allda]

OCP runs containers with an arbitrary UID but GID 0. The cargo home at /opt/_internal/rust-${RUST_VERSION}/cargo/ was created by rustup with default 755 permissions (root-owned, group read-only), causing cargo to fail with Permission denied when trying to create the registry cache at runtime.

Add chmod -R g+w after copying the cargo home to manylinux-rootfs so non-root container users with GID 0 can write to it.

Summary by Sourcery

Enable Cargo cache creation for non-root OpenShift containers by making the runtime cache directories group-writable.

Bug Fixes:

• Allow arbitrary-UID, GID 0 OpenShift containers to create Cargo registry and Git caches at runtime without permission errors.

Build:

• Adjust the Rust runtime image’s Cargo cache directories to be group-writable while keeping executables non-writable.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

The Rust build script now recursively grants group-write access to the copied Cargo home, allowing OpenShift containers running with arbitrary UIDs and GID 0 to create the registry cache at runtime.

Sequence diagram for group-writable Cargo home in OCP containers

sequenceDiagram
    participant Build as Rust build script
    participant Rootfs as manylinux-rootfs
    actor User as OCP container user
    participant Cargo as Cargo

    Build->>Rootfs: cp -r CARGO_HOME
    Build->>Rootfs: chmod -R g+w PREFIX/cargo/
    User->>Cargo: Run cargo with GID 0
    Cargo->>Rootfs: Create registry cache
    Rootfs-->>Cargo: Write permitted

Loading

File-Level Changes

Change	Details	Files
Make the copied Cargo home writable by OpenShift arbitrary-UID containers using group permissions.	Recursively add group-write permission after copying Cargo home into the manylinux root filesystem. Target the existing Cargo installation path while preserving the current Rustup copy and wrapper setup.	builder/build_scripts/build-rust.sh

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="builder/build_scripts/build-rust.sh" line_range="54" />
<code_context>

+# OCP runs containers with an arbitrary UID but GID 0. Make the cargo home
+# group-writable so non-root users can create the registry cache at runtime.
+chmod -R g+w /manylinux-rootfs"${PREFIX}"/cargo/
+
 # Create wrapper scripts that set environment variables
</code_context>
<issue_to_address>
**🚨 issue (security):** The recursive mode change makes every file under the Cargo home, including the `cargo`, `rustc`, and `rustup` executables and installed toolchain contents, group-writable. Any container process running with GID 0 can replace those executables or sources, so subsequent builds or commands execute attacker-controlled content instead of only allowing registry-cache writes.

**Triggers:** When multiple users or workloads share the image and one of them can run with GID 0.

**Suggested fix:** Restrict group write access to the runtime cache directories, or at minimum exclude executable and toolchain files from the recursive permission change.

```suggestion
mkdir -p /manylinux-rootfs"${PREFIX}"/cargo/{registry,git}
chmod -R g+w /manylinux-rootfs"${PREFIX}"/cargo/{registry,git}/
```
</issue_to_address>

Sourcery assessment

Needs a human reviewer. 1 finding to address first, and the recursive chmod changes the container's permission boundary: any process running with GID 0 can modify the Cargo registry and cache, potentially replacing dependencies or build inputs used by later cargo operations. Reverting prevents the permission change in future images but does not undo files already modified in running containers, and the overly broad access would not necessarily produce an operational failure.

Blocking findings: builder/build_scripts/build-rust.sh:54

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[jvulgan]

Change itself LGTM, @Allda can you just squash the commits before merging?

[Allda]

@jvulgan done