Bug 1967550

+++ This bug was initially created as a clone of Bug #1966519 +++

Description of problem:
We would like to ship the Security Profiles Operator in OpenShift. One of the things it does is record syscalls that the workload is doing with the seccomp-bpf hook. So we'd like to include the seccomp-bpf hook in RHCOS, but because RHCOS tries to have a minimal footprint, we need to trim the dependencies down a bit. The most critical parts are really the python libraries (python is not allowed on RHCOS), but the fewer packages, the better in general.

It seems that the simplest way would be to not require bcc-tools but  instead Recommend them. That way, we'd retain backwards compatibility, while environments where the tools are not required could choose not to install them.

Version-Release number of selected component (if applicable):
bcc-0.20.0-1.el8.1.x86_64

How reproducible:


Steps to Reproduce:
1. yum install bcc
2.
3.

Actual results:
bcc installs bcc-tools which brings in python3-bcc, python3-netaddr, kernel-devel etc

Expected results:
no python, no kernel-devel

Additional info:
The openshift enhancement proposal can be find at https://github.com/openshift/enhancements/pull/745 and our team's tracker to include the seccomp hook can be found at https://issues.redhat.com/browse/CMP-927

--- Additional comment from Jerome Marchand on 2021-06-01 13:10:31 UTC ---

(In reply to Jakub Hrozek from comment #0)
> Description of problem:
> We would like to ship the Security Profiles Operator in OpenShift. One of
> the things it does is record syscalls that the workload is doing with the
> seccomp-bpf hook. So we'd like to include the seccomp-bpf hook in RHCOS, but
> because RHCOS tries to have a minimal footprint, we need to trim the
> dependencies down a bit. The most critical parts are really the python
> libraries (python is not allowed on RHCOS), but the fewer packages, the
> better in general.
> 
> It seems that the simplest way would be to not require bcc-tools but 
> instead Recommend them. That way, we'd retain backwards compatibility, while
> environments where the tools are not required could choose not to install
> them.

I'm not quite sure why bcc depends on bcc-tools: that seems unnecessary. I'll try to find if the were a valid reason for it, but my guess would be there never really was one.

> 
> Version-Release number of selected component (if applicable):
> bcc-0.20.0-1.el8.1.x86_64
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1. yum install bcc
> 2.
> 3.
> 
> Actual results:
> bcc installs bcc-tools which brings in python3-bcc, python3-netaddr,
> kernel-devel etc
> 
> Expected results:
> no python, no kernel-devel
> 
> Additional info:
> The openshift enhancement proposal can be find at
> https://github.com/openshift/enhancements/pull/745 and our team's tracker to
> include the seccomp hook can be found at
> https://issues.redhat.com/browse/CMP-927

--- Additional comment from Jakub Hrozek on 2021-06-02 08:01:06 UTC ---

(In reply to Jerome Marchand from comment #1)
> (In reply to Jakub Hrozek from comment #0)
> > Description of problem:
> > We would like to ship the Security Profiles Operator in OpenShift. One of
> > the things it does is record syscalls that the workload is doing with the
> > seccomp-bpf hook. So we'd like to include the seccomp-bpf hook in RHCOS, but
> > because RHCOS tries to have a minimal footprint, we need to trim the
> > dependencies down a bit. The most critical parts are really the python
> > libraries (python is not allowed on RHCOS), but the fewer packages, the
> > better in general.
> > 
> > It seems that the simplest way would be to not require bcc-tools but 
> > instead Recommend them. That way, we'd retain backwards compatibility, while
> > environments where the tools are not required could choose not to install
> > them.
> 
> I'm not quite sure why bcc depends on bcc-tools: that seems unnecessary.
> I'll try to find if the were a valid reason for it, but my guess would be
> there never really was one.

Great, thank you very much for looking into this. I wonder if you already plan on updating bcc in the near future so I could take time timing into account? Is there maybe already a z-stream update that this could be attached to or were you thinking 8.5?

--- Additional comment from Jerome Marchand on 2021-06-03 10:54:30 UTC ---

(In reply to Jakub Hrozek from comment #2)
> Great, thank you very much for looking into this. I wonder if you already
> plan on updating bcc in the near future so I could take time timing into
> account? Is there maybe already a z-stream update that this could be
> attached to or were you thinking 8.5?

There should be no trouble for 8.5. There is no z-stream update planed atm.