Disabling Nexus changes /cf/conf/config.xml permissions, breaks config.xml scp-only access

marcg

I have a script that copies /cf/conf/config.xml to a remote machine nightly. The copy is done by scp from the remote machine using an account configured as scp-only on pfsense.

When Nexus is disabled by unticking the System > Advanced > NexusNetgate > Enable box, the permissions on /cf/conf/config.xml are changed to 600, root:wheel. The scp fails in that case. Setting permissions to 644, root:wheel, restores scp access.

The permission change appears to happen only upon disabling Nexus. The 644, root:wheel, permissions are preserved (a) across reboots when Nexus is enabled and (b) when enabling Nexus.

Running 26.03.1.

marcosm

We'll get that fixed, thanks!

marcg

@marcosm Thanks!

JeGr

@marcosm said in Disabling Nexus changes /cf/conf/config.xml permissions, breaks config.xml scp-only access:

We'll get that fixed, thanks!

@marcosm
As my post could be related to that:
-> https://forum.netgate.com/topic/201117/wrong-filesystem-rights-on-config.xml/1

I'll ask the same question here:

Is there a "correct" umask and what?
Could we "change" the group and permissions to a) better protect the configs but b) still allow config backups via scripting? My idea was along the lines of Linux logfiles that are often root/adm owned. Could we make configs and audit configs root/backup instead of root/wheel and make them 0640 so the backup group can read the file but not write? With that a backup user with SSH key could only copy and read the file but could NOT do anything executive on the system like restart or delete stuff owned by root AND it wouldn't accidentally get sudo by the default sudo package wheel group inclusion so would be far more limited as a wheel group user.

Cheers
\jens

marcosm

I wondered as well but I don't have an answer. One would need to go through the commit history of the project to understand 1) why it was done like that (if on purpose) and 2) determine what it should be along with 3) fixing any fallout. Personally I prefer the 600 permission and have been running that for a long time, however I don't use scripts that would otherwise be affected. Anyway changing the permissions should be a purposeful change so we'll restore the "intended" behavior.

marcg

@marcosm Since enabling Nexus, I've noticed that other config changes, not related to Nexus, also change config.xml permissions.

Could be a coincidence, but thought I'd flag it.

JeGr

@marcosm
After 26.07 Release we now have customers with the same problem. Is there a fix or patch incoming for this? Most customers backup their config via SFTP or tooling around Ansible and SSH so non-readable config.xml because of a changed permission set is really unfortunate. Could that be fixed via a system patch soon?

marcosm

We will be releasing an update to the Nexus package that includes this fix.

marcg

As a workaround, I installed the "cron" package and created a job to reset the permissions of config.xml just prior to scheduled nightly scp backups.