Wrong filesystem rights on config.xml?

JeGr

Hi,

we checked reports from various customers that their backup scripts won't work anymore. Normally they'd create a backup kinda user and gave it scp permissions, added a SSH key to it and thus copied config.xml from the device. That seemed to work since a few weeks ago. We checked that in our lab on various VMs and our own hardware boxes and the results are ... mixed?!

Some VMs show a permission set of 0600 for config.xml (so only root has rw) while others show 0644 that allows others to copy the file. The same for the audit history in /cf/conf/backup/ but there it was getting even more "mixed". We saw a system (like our dev-VM) that shows almost only 0600 permissions but 2-3 ones (on Aug 7) with 0644 (??) though.
Another system had all files with 0644 while another again had 0644 right up until a specific date and since then runs on 0600.

So it seems the "correct" permissions are all over the place?
What is the correct permission set and is it possible that it at least stays at 0640 thus denying world/all users rights to view the config files but retain a group "read" allowance so one can create a non-root user to copy it off-device without using the root user? Could we set the group to e.g. "backup" instead of wheel only allowing a backup group? Something along the lines of Linux Logfiles that are "root"/"adm" or some variation of that?

Yes free scp/sftp access is "nearly" identical to full admin but a user with that group can't e.g. just start/stop/restart services via SSH/CLI freely and if the configs aren't owned by "root"/"wheel" but some other group, the backup user doesn't even accidentally gets sudo permissions either so is mainly restricted to things it can read thus much better then using root or a wheel-group user.

Thanks
\jens

patient0

@JeGr something similar to https://forum.netgate.com/topic/201109/disabling-nexus-changes-cf-conf-config.xml-permissions-breaks-config.xml-scp-only-access ?

JeGr

Quick set of screenshots to show the different settings:

on a Lab 26.03.1 (stable) machine:

on a devel machine:

on a customer system:

but

So I really don't see a "correct" setting even with the same versions?

JeGr

@patient0 said in Wrong filesystem rights on config.xml?:

@JeGr something similar to https://forum.netgate.com/topic/201109/disabling-nexus-changes-cf-conf-config.xml-permissions-breaks-config.xml-scp-only-access ?

Could very well be a side effect of that. Perhaps some customers checked out Nexus after the blog post thus activating it, others didn't? Maybe that's the thing that binds it together.

marcg

@JeGr said in Wrong filesystem rights on config.xml?:

Could very well be a side effect of that. Perhaps some customers checked out Nexus after the blog post thus activating it, others didn't? Maybe that's the thing that binds it together.

It may be a broad issue with config updates when Nexus is enabled. The overnight scp of config.xml failed on my system last night, again because permissions had changed to 600. I made two changes to the config yesterday, neither of which was related to Nexus: updated apcupsd, and enabled System>Advanced>Miscellaneous>IPSec-MB . One of those must have caused the permissions change.

I don't make many changes to the config nowadays, but this changing of permissions seems like a new issue. I've used scp for config backup for, literally, years. I don't recall this behavior prior to enabling Nexus on 26.03.1.

EDIT Just applied the system patches v2.3.4 to 26.3.01 with Nexus enabled. config.xml permissions reverted to 600.