Context: opm had a bug that meant a copy of the sqlite database would be placed at the root of the filesystem and with the PSA changes nerfing privileges to be in line with the restricted profile, this results in a Permission Denied error at the fs level.

As a user with a customly built registry based off the old (buggy) version of opm, I would still like to be able to run it on newer versions of OCP with PSA enabled, because I have no other way to rebuild the registry with the current (patched) version of opm (e.g. lack the operational control to make the change)

Open Questions:

• Do such bounded features that require toggling by the user anyway and are off by default require a feature flag during intermediate sprints and then only activated before GA? Or can we ship them as is? jlanford@redhat.com 

Notes:

I think the right way to approach this is to toggle the PSA changes made to the Catalog Source pod. If it's on, we produce pods exactly as we did before the PSA changes. If off (by default) the PSA changes will be there. There is a caveat here that the namespace in which the pod will be schedule cannot enforce the restricted profile. This means this will not work in `openshift-*` namespaces, but can work in custom namespaces iff the cluster admin allows (labels the namespace accordingly) or the user can label the namespace. All of this should be called out in the API documentation with a link to migration instructions. Please double-check with Joe, Kevin and Ben that this is acceptable.
 

A/C:

• The CatalogSource API exposes a toggle to allow the user to still execute their legacy registry on newer OCP versions with the caveat that it will be executed with more privileges than necessary
• API documentation makes the security implications clear to the user
• Documentation exists to inform the user how to remediate the issue (e.g. rebuild catalog with latest opm)
• Link to documentation is present in the API documentation
• Let docs team know about this issue when it is ready to downstream