Hi,

seems like the reload script from the Upstream is a complete mess. Basically even if we use non-integrated configs(separate .conf files for each daemon), the reload script needs frr.conf to be present and to have some content for this to work, otherwise there are many errors with this:

Scenario 1 - no frr.conf(I believe that in 7.0 version of frr, the frr.conf was not even used at that time, so I don't know why this should happen):
1. systemctl start frr
2. systemctl reload frr
Job for frr.service failed.
See "systemctl status frr.service" and "journalctl -xe" for details.
3. systemctl status -l frr
frr[20552]: Unable to read configuration file /etc/frr/frr.conf. Only supporting integrated config
frr.service: frr.service: Control process exited, code=exited status=1
systemd[1]: Reload failed for FRRouting (FRR).

Scenario 2 - create empty /etc/frr/frr.conf:
1. systemctl start frr
2. touch /etc/frr/frr.conf
3. systemctl reload frr

As a result - you get the AVC and permission errors and the traceback that is desrcibed in this bug.

Senario 3 - create /var/log/frr/frr-reload.py:
1. systemctl start frr
2. touch /var/log/frr/frr-reload.py
3. systemctl reload frr

FRR complains that the frr.conf is empty and the reload process exits with code 1

Scenario 4 - have some nonsense content in frr.conf:
1. systemctl start frr
2. echo hello > /etc/frr/frr.conf
3. systemctl reload frr
Apr 27 03:07:39 ci-vm-10-0-138-102.hosted.upshift.rdu2.redhat.com frr[20624]: subprocess.CalledProcessError: Command '['/usr/bin/vtysh', '-m', '-f', '/etc/frr/frr.conf']' returned non-zero exit status 2.
frr[20624]: During handling of the above exception, another exception occurred:
frr[20624]: Traceback (most recent call last):
frr[20624]:   File "/usr/lib/frr/frr-reload.py", line 1145, in <module>
frr[20624]:     newconf.load_from_file(args.filename)
frr[20624]:   File "/usr/lib/frr/frr-reload.py", line 131, in load_from_file
frr[20624]:     raise ve
frr[20624]: __main__.VtyshMarkException: Command '['/usr/bin/vtysh', '-m', '-f', '/etc/frr/frr.conf']' returned non-zero exit status 2.
systemd[1]: frr.service: Control process exited, code=exited status=1
systemd[1]: Reload failed for FRRouting (FRR).

A different traceback because the config option is nonsense.

Scenario 5 - have some config in frr.conf that makes sense:
1. systemctl start frr
2. echo "bgp extcommunity-list standard user permit rt 65001:80"  > /etc/frr/frr.conf
3. systemctl reload frr

Success but the problem now is, that frr ignores all other config files for other daemons and only reads from frr.conf. This should not happen in 7.0 because at that time, all configs were being read from separate config files.

The bottom line is, that apparently the reload script at the time was already prepared for integrated configuration(one config to rule them all - frr.conf) and it is not complatible with our version of FRR in RHEL8. Even the newer version in RHEL-8.4.0 where we use 'no service integrated-vtysh-config' in vtysh.conf to disable integrated configuration, is unable to use the reload command. When you try, following error is produced:
frr[21133]: 'service integrated-vtysh-config' is not configured, this is required for 'service frr reload'
systemd[1]: frr.service: Control process exited, code=exited status=1

I don't see a way out of this in RHEL8 unless the user wants to use the integrated frr.conf for all daemons. The good thing here is, that the reload script does not break the running instance of frr.

I thought that a change similar to this would help with the SELinux issue:
https://src.fedoraproject.org/rpms/frr/c/c0bc1c720af50804bdea5a39a74032e9821cd6f5?branch=rawhide

But there seems to be something hardwired in the older version. I know that this is not ideal but at this point I would simply recommend not to use the reload function with frr. If the customer insists that they absolutely need this to work, please let me know and I will dig into it and try to fix it. My conclusion is that the reload was not meant to be used for this version of FRR, but it is already there so we need to figure this out.

I think you are right, the path /usr/lib/ffr is not correct since there is no reason ffr would execute in init_t context (which is implied here since /usr/lib is labeled with lib_t).
Whereas with /usr/libexec, this would end up becoming unconfined_service_t.

Note that there is a variant of scenario 5 which fails:

Scenario 5b - have some config in frr.conf that makes sense before starting frr:
1. echo "bgp extcommunity-list standard user permit rt 65001:80"  > /etc/frr/frr.conf
2. systemctl start frr
3. systemctl reload frr

Fails with the SELinux error.
 

This is the natural order when writing an Ansible playbook to configure a host - first template out the config files, then start the service, then do a (superfluous) reload.

Hi Jiri,

Would it make sense to you to create a custom context for /usr/lib/frr at installation time of frr?

~~~
# semanage fcontext -a -t bin_t "/usr/lib/frr(/.*)?"
# restorecon -Fr /usr/lib/frr
~~~

This would mimic the Fedora frr which has binaries in /usr/libexec/frr instead of /usr/lib/frr, hence will make sure the service runs as unconfined_service_t.

Hi Renaud,

I'm not the maintainer of frr (or indeed any RHEL package), so I have no particular opinion on the details. I would expect scenario 5b to work out of the box, and I would expect scenarios 5 and 5b to have identical outcomes.

Hi Jiri, sure I know you are not the maintainer.
It's just a proposal to test that the solution above would be acceptable to you.
If so I will then create a KCS linked to the Red Hat case you opened some time ago to deal with this.

I'm afraid I don't have the SELinux expertise to evaluate the proposal, sorry!

(In reply to Jiri Baum from comment #4)
> Note that there is a variant of scenario 5 which fails:
> 
> Scenario 5b - have some config in frr.conf that makes sense before starting
> frr:
> 1. echo "bgp extcommunity-list standard user permit rt 65001:80"  >
> /etc/frr/frr.conf
> 2. systemctl start frr
> 3. systemctl reload frr
> 
> Fails with the SELinux error.
>  
> 
> This is the natural order when writing an Ansible playbook to configure a
> host - first template out the config files, then start the service, then do
> a (superfluous) reload.

Hi Jiri,

but the point of reload command(at least for FRR here) is to apply config changes without reloading the service. Ideally this scenario 5b should work since there are no changes in the config between start and reload. The scenario 5 should simulate the situation where you start the service, let it run for a while, add some config and just reload. Like I said in comment #1, the reload script is a mess.

Michal

Hi Michal,

Exactly, scenarios 5 and 5b should both work.

Currently, only 5 works and 5b fails.


Jiri

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: frr security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2801