** Description changed: + [ Impact ] + When netplan generate or netplan apply is executed under a restrictive umask such as 0077 (for example, by virtualization guest agent scripts or administrative automation), files created in /run/systemd/network/ inherit mode 0600 instead of 0640. While netplan chowns the files to root:systemd-network, it does not explicitly chmod them. Consequently, unprivileged systemd-networkd cannot read /run/systemd/network/10-netplan-*.network (logging "Permission denied"), drops management of network interfaces, and guest networking fails. + + [ Fix ] + Explicitly call chmod(full_path, (mode_t)mode) after chown() in _netplan_g_string_free_to_file_with_permissions() whenever a mode is specified. This ensures target file permissions (such as 0640) are strictly enforced regardless of the caller's umask. A dedicated C unit test test_util_free_to_file_with_permissions_umask() is added to test_netplan_misc to prevent regressions. + + [ Test Plan ] + 1. Boot a clean Ubuntu instance (resolute or stonking). + 2. Set umask to 0077 and run netplan generate: + sudo -i + umask 0077 + netplan generate + 3. Inspect file permissions of generated networkd files: + ls -la /run/systemd/network/ + 4. With unpatched netplan, files are mode 0600 (-rw-------) and "sudo -u systemd-network cat /run/systemd/network/10-netplan-*.network" fails with Permission denied. + 5. With patched netplan, files are mode 0640 (-rw-r-----) and readable by systemd-network. + 6. Verify C unit tests pass: + meson test -C <builddir> test_netplan_misc + + [ Where problems could occur ] + The change only applies explicit chmod() to files written with _netplan_g_string_free_to_file_with_permissions() where mode > 0. If a caller previously relied on a restrictive umask to intentionally hide netplan-generated files in /run/systemd/network from group systemd-network, those files will now have group-read permission as specified by netplan's internal file creation mode (0640). This is the intended behavior since systemd-networkd requires group-read to operate. + + [ Other Info ] + - Upstream PR: https://github.com/canonical/netplan/pull/614 (merged into main as commit b74171cdac69029f02942d8e59cd08a6ada9ec7a). + - Devel series (stonking 26.10): debdiff provided for 1.2.2-3ubuntu1 (first Ubuntu delta against Debian sync 1.2.2-3). + - Stable SRU (resolute 26.04 LTS): debdiff provided for 1.2-1ubuntu5.2 (against 1.2-1ubuntu5.1 in resolute-updates). + - Test suites: cmocka unit test suite (test_netplan_misc) passes 100%. + + --- [ Original Report ] Hi, I'm seeing a permissions problem when Netplan is called by Parallels Tools after restoring a suspended VM. The guest is Ubuntu 26.04 LTS arm64 and the network is managed by systemd-networkd. After restoring the VM, Parallels Tools runs its network restart script: /usr/lib/parallels-tools/tools/scripts/debian-restart.sh The script detects that enp0s5 is managed by Netplan and calls: netplan apply The Parallels Tools process has umask 0077. After Netplan runs, the generated file has these permissions: -rw------- root systemd-network /run/systemd/network/10-netplan- enp0s5.network systemd-networkd cannot read the file and logs: Failed to open /run/systemd/network/10-netplan-enp0s5.network: Permission denied enp0s5: Unmanaging interface. The guest then loses its DHCP lease and network connectivity. I have to login into the Parallels terminal (it's a headless VM), change the permissions and restart networkd. After that it immediately restores the network: sudo chmod 0640 /run/systemd/network/10-netplan-enp0s5.network sudo systemctl restart systemd-networkd Interestingly, this does not happen after a normal reboot. During a reboot, /run is recreated and Netplan generates the file through the normal systemd startup path. The resulting permissions are 0640 and networking works. The difference appears to be the caller’s umask: * requested mode with boot umask: 0640 & ~0022 = 0640 * requested mode with Parallels umask: 0640 & ~0077 = 0600 (permission too restrictive) I can reproduce the underlying problem from the VM console with: sudo -i umask 0077 netplan generate ls -l /run/systemd/network/10-netplan-enp0s5.network The generated file is 0600. Looking online, it seems to be a recurrence of the problem reported in these older bugs: https://bugs.launchpad.net/bugs/1736965 https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1768560 As I understand it, Netplan intends to create the networkd file with mode 0640, but the final mode is still being affected by the caller’s umask. Would it be possible for Netplan to explicitly apply the requested ownership and mode to the generated temporary file before renaming it? That would make the generated files independent of the environment from which Netplan was called. Thank you.
** Tags added: resolute stonking -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2164636 Title: Netplan generates unreadable networkd files when called with umask 0077 To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2164636/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
