Skip to content

🐛 set the SElinux type #1939

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

Closed
wants to merge 1 commit into from
Closed

🐛 set the SElinux type #1939

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
3 changes: 3 additions & 0 deletions config/components/tls/operator-controller/patches/manager_deployment_cert.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,6 @@
- op: add
path: /spec/template/spec/containers/0/args/-
value: "--tls-key=/var/certs/tls.key"
- op: add
path: /spec/template/spec/securityContext/seLinuxOptions
value: {"type":"spc_t"}
Copy link
Contributor

@camilamacedo86 camilamacedo86 Apr 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Hey 👋

I wanted to share a quick note about this part of the change:

seLinuxOptions:
  type: spc_t

Just a heads up: in SELinux, spc_t stands for "Super Privileged Container". It grants elevated privileges and relaxes some of the default confinement SELinux provides — which might not be something we want to apply by default, especially if it's not strictly necessary.

That said, I totally get that you're trying to address an issue here — but I think the root cause may not be related to SELinux permissions. The error message you're seeing appears to be TLS-related:

error creating image source: pinging container registry https://my-route-jian.apps.heli-419.qe.devcluster.openshift.com/v2/: tls: failed to verify certificate: x509: certificate signed by unknown authority

This looks more like a trust/handshake problem with the registry's certificate rather than a container-level permissions issue. I'm not sure how granting additional SELinux privileges would help in this scenario. We might still unable to get the right cert, but how could that solve it out? What are your thoughts about this one?

Moreover, it is an issue that does not occur in upstream,, so I do not think that, if required, we should add the path to grant permissions here.

Would you mind explaining a bit more about why you think this is the right solution? Totally open to learning more if there’s something I’m missing.

Thanks! 🙏

Copy link
Contributor

Choose a reason for hiding this comment

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

Could we close this one as deferred?
@tmshort @jianzhangbjz WDYT?

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for reviewing! The root cause of this issue is Permission denied, which means the container's default process cannot access the /etc/docker.

jiazha-mac:~ jiazha$ oc exec catalogd-controller-manager-5c768bcf55-fk9ws -- ls -R /etc/docker
ls: cannot open directory '/etc/docker': Permission denied

I closed it since it is an issue that does not occur in upstream.

Loading