Open vbotbuildovich opened 2 months ago
Assuming this is infra issue. If not please reassign to Core, @jackietung-redpanda (cc: @michael-redpanda )
This is a real issue for rpk-fips
. When a plugin (such as this mocked out byoc plugin) is exec'd by rpk-fips
, it inherits LD_LIBRARY_PATH=/opt/redpanda/rpk-fips/lib
, which makes the plugin also try to use the libc.so.6
that we shipped alongside rpk-fips
(and meant for exclusive use by rpk-fips
.
This reveals that, in general, plugins (which could be any old executable provided by the user) probably should not load he shared libs that we ship as part of rpk-fips
. If we agree with this premise, we should make a change in rpk
code to explicitly not propagate LD_LIBRARY_PATH
, when we exec plugins in general. I think this is the way to go - based on the newbie context I have - team please chime in. cc @twmb @michael-redpanda
Or we completely shutoff the plugin capabilities for rpk-fips
- this seems like an excessive restriction for the end user though. Such a shutoff would require some code change in rpk too, to give nice user messaging (specific to FIPS mode).
Notes:
libc.so.6
is missing symbols that this specific mock plugin wants, but this is secondary IMO. It will be hard to guarantee the compatibility of our so's with all possible plugins, anyway.Echoing comment from Slack -- I think we can gate plugin stuff on a build tag. This will require a separate root.go file in the rpk source tree; currently the file that installs all commands also has a huge chunk dedicated to plugin discovery.
Wonder if we have a path forward here to close this out, @jackietung-redpanda ?
Yes we do. The plan is to block conditionally compile out plugins path for FIPS. However this work is considered non-blocking for the FIPS projects and will be prioritized accordingly.
In the meantime, I plan to merge this #18577 to clean up test reports. I think that will be sufficient to close out this issue.
https://buildkite.com/redpanda/vtools/builds/13607
JIRA Link: CORE-2849