Bluechi daemon fails when run in a rootless container with --network=host

[rhatdan]

Describe the bug

Please enter a clear and concise description of what the bug is.

To Reproduce

Please provide the steps to reproduce the issue.

$ podman run --device /dev/fuse --replace --cap-add=all --network=host --name autosd --security-opt label=disable -d quay.io/centos-sig-automotive/autosd:latest
$ podman exec -ti autosd systemctl status bluchi

If I remove --network=host bluechi works, so I believe is is attempting to do something that is not allowed by default unless you setup a different network. Issue is I could not find where bluechi printed an error message telling me why it fails.

Expected behavior

Please describe what you would expect to happen.

Expected Bluchi to work with --network=host.

[engelmi]

The default logging sink should be journald. Could you post the logs returned by podman exec -it autosd journalctl -u bluechi and podman exec -it autosd journalctl -u bluechi-agent? @rhatdan

[ygalblum]

@rhatdan

The issue is with the Bluechi controller default port. By default, the controller port is 842. When running as rootless with network=host this translates to a non-root application trying to open a privileged (<1024) port.
I was able to start the controller after changing the port in the configuration file. I used 8420, but I guess any number above 1024 will work.

In addition, please note that there is an typo in the 00-default.conf file in the image in which managerPort is set instead of ManagerPort.

If we do intend to run such a configuration (that is rootless on the host network), maybe we should rethink the default port.

[rhatdan]

SGTM and good find.
@engelmi @dougsland @Yarboa Thoughts?

[dougsland]

SGTM and good find. @engelmi @dougsland @Yarboa Thoughts?

Make sense @ygalblum explanation. If bluechi is not changing the default port, we must document this in bluechi docs session adding @engelmi in the loop.

[engelmi]

Nice catch! @ygalblum
As far as I can remember having a default port < 1024 was a security concern - so that you have to explicitly either open the port or configure a different one to be used. I am not sure if we should still stick to this considering the rootless use case. I think that just adding a config file is simple enough to keep it. Yet it's still a way to cause a setup error.
What do you think? @rhatdan @dougsland @ygalblum

[ygalblum]

I don't know. Maybe we can also ask should we allow running this container rootless with network=host. For example, some web server containers will also fail to start with this configuration as they try to open ports 80 or 443.