Upgrade process changes /config/auth/wireguard permissions causing commit fail

[dcava]

Following the upgrade instructions on a USG3 - the final "commit" step fails with error:

"Error: Private key /config/auth/wireguard/wg_private.key not found"

even though this file does exist. The error message comes from

opt/vyatta/share/vyatta-cfg/templates/interfaces/wireguard/node.tag/private-key/node.def

It looks like either one of the install script steps or the commit itself removes the setgid bit and removes "all" permissions. If I recreate the "wireguard" dir and copy back across the keys the commit succeeds. This is what it looks like on ls:

 4 drwxr-sr-x    2 root     vyattacf      4096 May 11 11:48 wireguard
 4 drwxr-S---    2 root     vyattacf      4096 Mar 19 14:46 wireguardold`

I can't see anything in repo that changes anything, and I presume it's a called script from the `vyatta/sbin' dir that causes the prob, but I can't hunt it down.

Can anyone else confirm this occurs on their setup?

[FossoresLP]

Hi, thanks for reporting. I will try to reproduce this on my ER-8-Pro later today and take a look where this permission change could be coming from.

[dcava]

Thanks @FossoresLP.

Interestingly, it happened on another USG3 and rather than do anything specific, I just reboot and it worked on reboot (whilst still keeping the dir permissions).

I was looking through the Vyatta/VyOS documentation, and I wonder if it may have anything to do with this scripting issue outlined on https://docs.vyos.io/en/latest/appendix/command-scripting.html ?

Executing Configuration Scripts
There is a pitfall when working with configuration scripts. It is tempting to call configuration scripts with “sudo” (i.e., temporary root permissions), because that’s the common way on most Linux platforms to call system commands.

On VyOS this will cause the following problem: After modifying the configuration via script like this once, it is not possible to manually modify the config anymore:

sudo ./myscript.sh # Modifies config
configure
set ... # Any configuration parameter
This will result in the following error message: Set failed If this happens, a reboot is required to be able to edit the config manually again.

To avoid these problems, the proper way is to call a script with the vyattacfg group, e.g., by using the sg (switch group) command:

sg vyattacfg -c ./myscript.sh
To make sure that a script is not accidentally called without the vyattacfg group, the script can be safeguarded like this:

if [ "$(id -g -n)" != 'vyattacfg' ] ; then
    exec sg vyattacfg -c "/bin/vbash $(readlink -f $0) $@"
fi

Anyway, easy to fix manually for now.