Skip to content

NO-JIRA: fix: propagate custom image build for cryptoscan in main config #83025

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
openshift-merge-bot merged 1 commit into from
Aug 6, 2026
Merged

NO-JIRA: fix: propagate custom image build for cryptoscan in main config #83025

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions ci-operator/config/openshift/microshift/openshift-microshift-main.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,20 @@ images:
source_path: /go/src/github.com/openshift/microshift
optional: true
to: microshift-test-rpm
- dockerfile_literal: |
FROM src
USER 0
RUN dnf install -y podman shadow-utils jq file && dnf clean all && \
setcap cap_setuid+ep /usr/bin/newuidmap && \
setcap cap_setgid+ep /usr/bin/newgidmap && \
Comment on lines +29 to +30

@coderabbitai coderabbitai Bot Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== locate file =="
git ls-files | grep -F 'ci-operator/config/openshift/microshift/openshift-microshift-main.yaml' || true

echo "== relevant context =="
if [ -f ci-operator/config/openshift/microshift/openshift-microshift-main.yaml ]; then
  nl -ba ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,220p'
fi

echo "== occurrences of setcap/newuidmap/newgidmap in config =="
rg -n "setcap|newuidmap|newgidmap|chmod u-s|chmod.*u-s|runAsNonRoot|privileged|allowPrivilegeEscalation" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true

echo "== lockfile/tooling hints =="
git ls-files | rg '(^Makefile$|Makefile$|podman|Containerfile|Dockerfile|Dockerfile\.)|ci-operator/config' | head -200

Repository: openshift/release

Length of output: 307

🌐 Web query:

Red Hat namespace setup failures uidmap gidmap setuid bits file capabilities newuidmap newgidmap

💡 Result:

Namespace setup failures involving newuidmap and newgidmap in rootless environments—such as Podman on Red Hat Enterprise Linux—typically stem from issues with file permissions, system configuration, or insufficient mapping ranges. These binaries are setuid-root to allow unprivileged users to map subordinate UIDs/GIDs into a user namespace [1][2]. Common causes and troubleshooting steps include: 1. Verification of /etc/subuid and /etc/subgid These files must contain entries for the user attempting to run the container [3][2]. If a user lacks these mappings, or if the specified ranges are invalid (e.g., overlapping with the user's own UID or excluding required IDs), namespace setup will fail [4][5][2]. 2. File Permissions and Capabilities The newuidmap and newgidmap binaries must have the correct setuid bits and file capabilities to function [6][1]. - Verify that these binaries are setuid and possess the necessary capabilities (typically cap_setuid+ep and cap_setgid+ep) [4][7]. - Security hardening policies may sometimes restrict access to configuration files like /etc/login.defs. Ensure that /etc/login.defs is world-readable (0644); restricted permissions (e.g., 0640) can prevent these tools from reading necessary configuration, resulting in exit status 1 [8]. 3. Kernel and System Constraints - User namespaces must be enabled in the kernel [3]. - If logs show warnings regarding "both setuid-root and effective capabilities," it indicates a conflict between traditional setuid bits and file capabilities, which can prevent the binaries from operating correctly [6]. - In some cases, dmesg may provide more detailed error information, such as "Permission denied" or "invalid argument," which helps distinguish between configuration errors and actual permission/capability issues [6][4][7]. To troubleshoot effectively: - Use podman unshare to test whether your user namespace mapping is functioning correctly [3]. - Check for errors in the system logs (dmesg) related to newuidmap/newgidmap [6]. - Ensure your /etc/subuid and /etc/subgid ranges are sufficient and do not overlap with the host user's own UID [4][5]. - If you suspect permission issues on configuration files, verify the readability of /etc/login.defs [8].

Citations:

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== relevant context =="
awk '{printf "%6d: %s\n", NR, $0}' ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,220p'

echo "== occurrences =="
grep -nE "setcap|newuidmap|newgidmap|chmod .*s|chmod .*u-s|runAsNonRoot|privileged|allowPrivilegeEscalation|from .*podman|podman" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true

echo "== podman image/config hints in repo =="
grep -RInE "setcap|cap_setuid|cap_setgid|newuidmap|newgidmap|from .*podman|podman:" ci-operator/config openshift/microshift 2>/dev/null | head -200 || true

echo "== git file type info for changed file (if available) =="
git ls-files -s ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true

Repository: openshift/release

Length of output: 33886

🌐 Web query:

Red Hat solution 7110510 setuid effective file capabilities newuidmap newgidmap

💡 Result:

Red Hat Knowledgebase Solution 7110510 addresses an issue where the podman command fails with an error related to newuidmap, specifically: "Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1" [1]. This failure is often accompanied by a kernel warning in dmesg stating that /usr/bin/newuidmap has both setuid-root permissions and effective file capabilities [1]. When a binary possesses both, the kernel may prevent it from operating correctly to maintain security boundaries [1]. The issue stems from a conflict where the shadow-utils package binaries (/usr/bin/newuidmap and /usr/bin/newgidmap) are misconfigured in certain environments, such as container images, by having both the setuid bit and file capabilities set simultaneously [1][2][3]. To resolve this issue, the standard recommendation is to ensure that the file capabilities are correctly set and that the setuid bit is removed or handled according to the system's security requirements [1][2][3]. If you encounter this on a RHEL system, you can often repair the file attributes by reinstalling the shadow-utils package or by using the rpm --setcaps command to reset the file capabilities to the values defined in the RPM package [2][3]. Reinstalling the package typically ensures the binaries receive the appropriate cap_setuid+ep and cap_setgid+ep capabilities without maintaining an improper setuid-root configuration [2].

Citations:

🌐 Web query:

openshift release setcap newuidmap newgidmap chmod u-s ci-operator

💡 Result:

The combination of commands chmod u-s, setcap, and the use of newuidmap/newgidmap is a common pattern used in OpenShift container images (such as CI/CD agents or build containers) to enable rootless container builds (e.g., using Podman or Buildah) [1][2][3]. In a standard Linux environment, newuidmap and newgidmap are setuid binaries that allow unprivileged users to map their own UIDs/GIDs in a new user namespace [4]. However, when building custom container images for use in OpenShift, these binaries may have their sticky/setuid bits set incorrectly or in a way that conflicts with container security policies (e.g., Security Context Constraints), causing permission errors during build operations [1][4]. The typical configuration pattern follows these steps: 1. chmod u-s /usr/bin/newuidmap and chmod u-s /usr/bin/newgidmap: This removes the setuid bit from these binaries [1][2]. This is often necessary because the setuid bit can be problematic or restricted within container runtimes, or it may have been set incorrectly by a base image's packaging process [1][4][5]. 2. setcap cap_setuid+eip /usr/bin/newuidmap and setcap cap_setgid+eip /usr/bin/newgidmap: After removing the setuid bit, file capabilities are applied to grant the specific necessary permissions (CAP_SETUID and CAP_SETGID) to these binaries [1][6][2]. This allows the binaries to perform their required mapping functions without requiring full root privileges for the entire process [7][3]. This configuration ensures that the container can perform rootless builds even when running with restricted permissions [1][3]. If these permissions are not correctly set, users often encounter errors such as "newuidmap: write to uid_map failed: Operation not permitted" [1][8][4]. Note: The ci-operator itself is an execution engine for OpenShift CI that manages ephemeral test clusters and build environments [9][10]. The ci-operator does not inherently mandate these specific binary configurations; rather, these configurations are applied within the Dockerfile/Containerfile of the build images (like Jenkins agents or custom runners) that ci-operator utilizes to perform containerized builds [1][2][9]. In newer versions of UBI images, some of this configuration may be handled automatically, reducing the need for manual setcap commands [3].

Citations:

🌐 Web query:

site:github.com/openshift/release "chmod u-s /usr/bin/newuidmap"

💡 Result:

Running the command chmod u-s /usr/bin/newuidmap removes the setuid (set-user-ID) bit from the /usr/bin/newuidmap binary. The newuidmap utility is a system tool used in conjunction with user namespaces, a security feature in the Linux kernel that allows unprivileged users to map their own user IDs (UIDs) and group IDs (GIDs) to a range of UIDs and GIDs within a container or namespace. Because this process requires elevated privileges to modify namespace mappings, newuidmap is typically installed with the setuid bit set, allowing it to run with root privileges regardless of the user executing it. By running chmod u-s, you disable this mechanism. As a result, unprivileged users will no longer be able to use newuidmap to configure user namespaces. This will break functionality for container runtimes and tools (such as Podman or certain build systems) that rely on user namespaces to run containers or build images without requiring full root access on the host system. In environments like OpenShift or other containerized platforms, such operations are restricted to ensure that security policies are maintained. Modifying the permissions of critical system binaries like newuidmap is generally not recommended unless you specifically intend to disable user namespace support, as it will likely lead to permission denied errors when performing operations that require unprivileged namespace mapping.

Citations:

🏁 Script executed:

#!/bin/bash
set -euo pipefail

tmp="$(mktemp -d)"
python3 - <<'PY' "$tmp"
import os, subprocess, tempfile
tmpdir = os.sys.argv[1]
for name in ("/usr/bin/newuidmap", "/usr/bin/newgidmap"):
    src = os.path.join(tmpdir, os.path.basename(name))
    os.symlink(name, src) if os.path.exists(name) else None
print("tmpdir", tmpdir)
PY

Repository: openshift/release

Length of output: 182

🌐 Web query:

Linux kernel file capabilities setuid bit setcap binary setuid setuid-root effective capabilities dmesg

💡 Result:

In the Linux kernel, file capabilities and the setuid bit serve as mechanisms to grant processes elevated privileges beyond those of an unprivileged user, but they function in fundamentally different ways [1][2][3]. Traditional setuid (set-user-ID) is a binary permission bit that, when set on an executable, causes the process to run with the effective user ID of the file owner (typically root) upon execution [1][4]. This results in a complete escalation of privileges, where the process bypasses all kernel permission checks, effectively granting the "root" superuser power [1]. Because this provides total control, any vulnerability in a setuid binary can lead to full system compromise [5]. Linux capabilities break down the monolithic power of the root user into discrete, fine-grained units (such as CAP_NET_BIND_SERVICE for binding to low-numbered network ports or CAP_DAC_OVERRIDE for bypassing file read/write checks) [1][2]. File capabilities allow these specific privileges to be assigned to binaries stored in the filesystem's extended attributes (specifically, the security.capability attribute) [2][6][7]. The setcap binary is the primary tool used to manage these file-based capabilities [2][8]. When used, setcap allows an administrator to grant only the necessary permissions required for a specific task without providing full root access [2][9]. Key operational details regarding these mechanisms include: 1. Interaction: If a binary has both the setuid bit set and file capabilities assigned, the setuid behavior generally takes precedence; a setuid-root binary typically ignores file capabilities and gains all capabilities from the root's bounding set [6]. 2. Visibility: The setuid bit is visible via standard commands like ls -l (appearing as an 's' in the user execute position), whereas file capabilities are not visible in standard directory listings [5][10]. To inspect or manage them, tools like getcap or getfattr are required [6][10]. 3. Security: Utilizing capabilities is a recommended hardening practice because it adheres to the principle of least privilege, limiting the potential impact of an exploit [5][3]. 4. Kernel Logging: While there is no single specific dmesg log entry just for "using a capability," security-related denials or violations involving capabilities are often reported via the kernel's audit system or through dmesg (e.g., via SELinux or AppArmor denials if those frameworks are active). In summary, replacing setuid with file capabilities is a security-conscious approach that replaces broad, all-or-nothing root privileges with narrow, task-specific permissions [1][2][3]. {1, 3, 4, 5, 6, 7, 8, 9, 10, 11}

Citations:

Clear setuid before applying file capabilities.

newuidmap and newgidmap come from shadow-utils with setuid-root mode. setcap alone adds file capabilities without changing that mode, and a setuid-root file plus effective file capabilities can make rootless Podman namespace setup fail. Before setcap, drop the setuid bits and add a short rootless Podman smoke test so the final image behavior is covered.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml`
around lines 29 - 30, The image setup commands for newuidmap and newgidmap must
clear their setuid-root bits before applying file capabilities. Update the
relevant installation sequence to remove setuid permissions, retain the
cap_setuid and cap_setgid capabilities, and add a concise rootless Podman smoke
test covering the final image behavior.

touch /etc/subgid /etc/subuid && \
chmod g=u /etc/subuid /etc/subgid
USER 1000

@coderabbitai coderabbitai Bot Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== locate files =="
fd -a 'openshift-microshift-rebase-cryptoscan-commands.sh|openshift-microshift-main.yaml|Dockerfile|Containerfile|Dockerfile.*|Containerfile.*' . | sed 's#^\./##'

echo
echo "== target yaml excerpt =="
sed -n '1,120p' ci-operator/config/openshift/microshift/openshift-microshift-main.yaml

echo
echo "== target script excerpt =="
while IFS= read -r f; do
  echo "--- $f"
  sed -n '1,240p' "$f"
done < <(fd 'openshift-microshift-rebase-cryptoscan-commands.sh' .)

echo
echo "== related registry files =="
for f in $(fd 'openshift-microshift-rebase.*|cryptoscan' ci-operator/step-registry/openshift/microshift 2>/dev/null | sort); do
  echo "--- $f"
  sed -n '1,220p' "$f"
done

Repository: openshift/release

Length of output: 4212

🌐 Web query:

raw.githubusercontent.com openshift release master ci-operator step-registry openshift microshift rebase cryptoscan openshift-microshift-rebase-cryptoscan-commands.sh

💡 Result:

The filename openshift-microshift-rebase-cryptoscan-commands.sh does not appear to exist in the standard OpenShift release step registry [1][2][3]. The MicroShift project uses an automated rebase process [3]. The primary script used in the CI environment is openshift-microshift-rebase-commands.sh [1][2], which is located in the ci-operator/step-registry/openshift/microshift/rebase/ directory of the openshift/release repository [4][3]. This script is responsible for executing the automated rebase workflow, which synchronizes MicroShift with upstream OpenShift release versions [3]. It is possible that the filename you mentioned is a misremembered name, a custom internal script, or a very recent addition not reflected in public documentation. If you are looking for how to manage or test MicroShift rebases, the authoritative resource is the documentation found in the microshift/docs/contributor/rebase/ directory, which details the procedures for using openshift-microshift-rebase-commands.sh to perform rehearsals and tests [1][4][3].

Citations:

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== target cryptoscan commands file raw =="
cat -n ci-operator/step-registry/openshift/microshift/rebase/cryptoscan/openshift-microshift-rebase-cryptoscan-commands.sh

echo
echo "== microshift rebase step files =="
fd -a . ci-operator/step-registry/openshift/microshift 2>/dev/null | sed 's#^\./##'

echo
echo "== workflow references =="
rg -n "openshift-microshift-rebase-cryptoscan|cryptoscan|HOME|pull-secret|\\.local/bin |/go/src/github.com/openshift/microshift" ci-operator/step-registry/openshift/microshift ci-operator/config/openshift/microshift -S

echo
echo "== related files excerpts =="
for f in $(git ls-files 'ci-operator/step-registry/openshift/microshift/*'); do
  echo "--- $f"
  wc -l "$f"
  sed -n '1,220p' "$f"
done

Repository: openshift/release

Length of output: 50374

Ensure HOME and worktree paths are writable before switching users.

The cryptoscan commands write to $HOME/.local/bin, $HOME/.pull-secret.json, and /go/src/github.com/openshift/microshift, but the image sets USER 1000 without initializing these paths. Create and ownership these paths before the user switch, or set HOME and chown the inputs if a writable home is expected.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml` at
line 33, Update the image setup before the USER 1000 directive to initialize the
cryptoscan-required HOME and worktree paths, including $HOME/.local/bin,
$HOME/.pull-secret.json, and /go/src/github.com/openshift/microshift, and assign
ownership to UID 1000. Set HOME consistently if needed so the cryptoscan
commands can write successfully after the user switch.

inputs:
src:
as:
- src
to: rebase-cryptoscan-src
Comment on lines +25 to +38

@coderabbitai coderabbitai Bot Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'Tracked target file:\n'
git ls-files | rg '(^|/)openshift-microshift-main\.ya?ml$' || true

printf '\nRelevant sections of openshift-microshift-main.yaml:\n'
if [ -f ci-operator/config/openshift/microshift/openshift-microshift-main.yaml ]; then
  nl -ba ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,180p'
fi

printf '\nSearch for rebase-cryptoscan-src and promotion exclusions:\n'
rg -n "rebase-cryptoscan-src|excluded_images|from_namespace|to:" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true

printf '\nGenerate/relevant make update output if available:\n'
if [ -f Makefile ]; then
  rg -n "^(update|generate|ci-operator|metadata)" Makefile || true
fi

Repository: openshift/release

Length of output: 341

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf 'Relevant sections of openshift-microshift-main.yaml:\n'
awk '{printf "%5d  %s\n", NR, $0}' ci-operator/config/openshift/microshift/openshift-microshift-main.yaml | sed -n '1,180p'

printf '\nSearch for rebase-cryptoscan-src and promotion exclusions:\n'
grep -nE "rebase-cryptoscan-src|excluded_images|from_namespace|to:" ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true

printf '\nGeneration metadata around promotion exclusions:\n'
git diff -- ci-operator/config/openshift/microshift/zz_generated_metadata || true
git diff -- ci-operator/config/openshift/microshift/openshift-microshift-main.yaml || true

Repository: openshift/release

Length of output: 6207

🌐 Web query:

ci-operator promotion excluded_images documentation

💡 Result:

In the OpenShift ci-operator configuration, the promotion.to[*].excluded_images field is used to specify a list of image names that should not be promoted to the target ImageStream [1][2]. By default, all images defined in the images block are promoted when a promotion stanza is configured; excluded_images provides a mechanism to prevent specific images from being published [3][4]. Key details regarding the use of excluded_images include: Exclusion Timing: Exclusions are applied before any additional_images are processed, meaning images listed in excluded_images will not be promoted even if they were built [2]. Wildcard Support: The * wildcard can be used to exclude all images for a specific promotion target [1][5]. This is particularly useful when you want to promote only specific, explicitly defined images via additional_images while preventing the automatic promotion of all other build images [1][6]. Purpose: It is primarily intended for scenarios where you need to build certain images for testing or intermediate steps within the CI pipeline but do not want them published to the final integration ImageStream [2]. Example configuration snippet [1][5]: promotion: to: - namespace: "ci" name: "cli-ocm" excluded_images: - "*" additional_images: latest: cli-ocm In this example, the * wildcard prevents the default promotion behavior, and only the cli-ocm image is promoted as specified in additional_images [1][5].

Citations:

Exclude rebase-cryptoscan-src from CI promotion.

rebase-cryptoscan-src is a test-only build image used by test-rebase, but it is implicitly included in promotion.to[*].excluded_images. Add it to the existing exclusion block so ci-operator does not publish it with the release output.

Proposed promotion update 
   - excluded_images:
     - microshift-test-rpm
+    - rebase-cryptoscan-src
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ci-operator/config/openshift/microshift/openshift-microshift-main.yaml`
around lines 25 - 38, Update the existing promotion exclusion block in the
MicroShift configuration to explicitly include rebase-cryptoscan-src in
promotion.to[*].excluded_images. Leave the test-only build definition and other
promotion exclusions unchanged.

promotion:
to:
- excluded_images:
Expand Down Expand Up @@ -86,7 +100,12 @@ tests:
steps:
workflow: openshift-ci-security
- as: test-rebase
capabilities:
- intranet
- nested-podman
nested_podman: true
optional: true
restrict_network_access: false
run_if_changed: ^(assets/.*|scripts/auto-rebase/.*|go\.mod|vendor/.*|deps/.*)$
steps:
env:
Expand Down
2 changes: 2 additions & 0 deletions ci-operator/jobs/openshift/microshift/openshift-microshift-main-presubmits.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2505,6 +2505,8 @@ presubmits:
decoration_config:
skip_cloning: true
labels:
capability/intranet: intranet
capability/nested-podman: nested-podman
ci.openshift.io/generator: prowgen
job-release: "5.0"
pj-rehearse.openshift.io/can-be-rehearsed: "true"
Expand Down