frr.conf won't retain permissions on write

[alchemyx]

Description

Whenever doing write integrated (or just write when service integrated-vtysh-config is there), frr changes permissions to 600 for /etc/frr/frr.conf. No matter what they were before.

Versions

FRR version - 7.5.4
OS - CentOS 8.5.2111
Kernel - 4.18.0-348.7.1.el8_5.x86_64

How to reproduce

# chmod 640 /etc/frr/frr.conf
# ls -la /etc/frr/frr.conf
-rw-r----- 1 frr frr 1555 Nov 17 07:11 /etc/frr/frr.conf
# vtysh -c 'write integrated'
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]
# ls -la /etc/frr/frr.conf
-rw------- 1 frr frr 1555 Nov 17 08:07 /etc/frr/frr.conf

Expected result would be to have still 640 on /etc/frr/frr.conf or at least have a configurable permissions (and group). We use this file for oxidized copy so even if oxidized is member of group frr it will still fail.

[ton31337]

Yes, it's expected and normal. This is regulated by --enable-configfile-mask. You can verify the value using show version.

[ton31337]

Looking deeper, I see we set 0640 for Debian-based, but not setting for RHEL-based.

[alchemyx]

Yes it looks like this confirms

# show version
FRRouting 7.5 (redacted).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--libdir=/usr/lib64/frr' '--libexecdir=/usr/libexec/frr' '--localstatedir=/var/run/frr' '--enable-snmp=agentx' '--enable-multipath=64' '--enable-vtysh=yes' '--enable-ospfclient=no' '--enable-ospfapi=no' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-rtadv' '--disable-exampledir' '--enable-systemd=yes' '--enable-static=no' '--disable-ldpd' '--disable-babeld' '--with-moduledir=/usr/lib64/frr/modules' '--with-crypto=openssl' '--enable-fpm' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

[ton31337]

Raised a fix here #14821.

[eqvinox]

I don't think changing it either direction is a real fix here, the only "reasonable" improvement I can see is to retain permissions (and owner group, but probably not owner user) from the previous file. (This doesn't happen automatically because the old config is renamed away to create the backup, and the new config is a "fresh" file. We could also create a new file for the backup — where the permissions don't matter as much — and then overwrite the existing file for "current" config, this would have the advantage of fully keeping all properties of the file, e.g. possible extra things like ACL.)

[alchemyx]

Retaining permissions and ownership would be the most reasonable as that the usual behaviour of other software i am working with. It's basically replacing contents in place.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot]

This issue will be automatically closed in the specified period unless there is further activity.