chore(meta): stop pinning community.general collection

[ptoscano]

The issues in the redhat_subscription module shipped in the community.general collection were fixed in version 6.6.0, so it should not have regressions now.

Hence, stop pinning the community.general collection.

This reverts commit 26c0f43.

[ptoscano]

Keeping it as draft until all the prerequisites are satisfied.

[ptoscano]

@richm @spetrosi please note the requirements, so for now this cannot go in. I'll keep it updated when it's possible to even test this.

[richm]

6.6.0 was released - https://galaxy.ansible.com/community/general

[ptoscano]

[citest]

[ptoscano]

Hmm there's something wrong with some scenarios in Fedora -- this will need more investigations.

[ptoscano]

OK, I see what's the problem: with newer dbus (1.12.24+ and 1.14.4+), the socket created as /run/dbus-* for a new D-Bus server (created to have a secure bus for the registration) is no more an abstract socket, but a real Unix socket file. The SELinux policy in Fedora does not allow rhsmcertd_t to create sockets, and thus it fails with EACCES as result of the SELinux denial. (There is also another issue in sub-man itself, as the failure when starting a new D-Bus server is not properly handled.)

I'll need to get this added in the Fedora SELinux policy first.

[richm]

OK, I see what's the problem: with newer dbus (1.12.24+ and 1.14.4+), the socket created as /run/dbus-* for a new D-Bus server (created to have a secure bus for the registration) is no more an abstract socket, but a real Unix socket file. The SELinux policy in Fedora does not allow rhsmcertd_t to create sockets, and thus it fails with EACCES as result of the SELinux denial. (There is also another issue in sub-man itself, as the failure when starting a new D-Bus server is not properly handled.)

I'll need to get this added in the Fedora SELinux policy first.

As an alternative - can we use the selinux system role to ensure this policy exists in the rhc role?

[ptoscano]

can we use the selinux system role to ensure this policy exists in the rhc role?

I don't think so. The fix for this would likely be allowing unix sockets operations to the rhsmcertd module, and I don't see this capability in the selinux role.

[richm]

can we use the selinux system role to ensure this policy exists in the rhc role?

I don't think so. The fix for this would likely be allowing unix sockets operations to the rhsmcertd module, and I don't see this capability in the selinux role.

@bachradsusi is it possible to do this with the selinux role?

[bachradsusi]

can we use the selinux system role to ensure this policy exists in the rhc role?

I don't think so. The fix for this would likely be allowing unix sockets operations to the rhsmcertd module, and I don't see this capability in the selinux role.

@bachradsusi is it possible to do this with the selinux role?

Using selinux role it would be possible to ship and install a local module which would allow this. But it would be just a temporary hack. It really needs to be enabled in rhsm selinux policy. cc @zpytela

[ptoscano]

But it would be just a temporary hack. It really needs to be enabled in rhsm selinux policy. cc @zpytela

Yes, I already contacted Zdeněk about this issue some days ago ;-)

[ptoscano]

The issues related to Fedora will be handled separately; this should be good for a EL-only POV.

[ptoscano]

[citest]