Hello Everybody, Allow me to give you a longer update on my progress.
1.) Managed to reproduce the issue on my machine. Big thanks to martintxo for the detailed repro steps. 2.) Checked dhcpcd-gtk with the bad case and based on the logs it seems that it has issues with the wpa_supplicant connection -------------------------8<----------------BEGIN------------------->8----------- pasja@bifrost ~ % dhcpcd-gtk (dhcpcd-gtk:346063): Gtk-WARNING **: 18:43:01.100: Theme parsing error: gtk-widgets.css:1214:18: Not using units is deprecated. Assuming 'px'. ** Message: 18:43:01.145: Connecting ... ** Message: 18:43:01.145: Status changed to down ** Message: 18:43:01.145: Status changed to opened ** Message: 18:43:01.145: Connected to dhcpcd-9.4.1 ** Message: 18:43:01.145: Status changed to connected ** Message: 18:43:01.145: wlo1: Associated with Ibn Tufajl ** Message: 18:43:01.145: wlo1: Configured 192.168.1.122/24 ** Message: 18:43:01.145: wlo1: Configured 2001:xxxx:yyyy:e700:4bdb:3e4:cd05:b45/64 ** Message: 18:43:01.145: wlo1: Configured 2001:xxxx:yyyy:e700::64f/128 ** Message: 18:43:01.145: eno2: Link is down ** Message: 18:43:03.148: wlo1: WPA status down ** Message: 18:43:05.152: wlo1: WPA status down -------------------------8<------------------END------------------->8----------- 3.) Went to check dhcpcd-gtk source and I have found out that there is a socket based communication between dhcpcd-gtk and wpa_supplicant https://salsa.debian.org/debian/dhcpcd-ui/-/blob/master/src/libdhcpcd/wpa.c#L56 4.) After that I have tried to connect to wpa_supplicant with wpa_cli, without any success. Based on that I have ruled out that the issue is in dhcpcd-gtk -------------------------8<----------------BEGIN------------------->8----------- root@bifrost /tmp # wpa_cli wpa_cli v2.10 Copyright (c) 2004-2022, Jouni Malinen <[email protected]> and contributors This software may be distributed under the terms of the BSD license. See README for more details. Selected interface 'wlo1' Interactive mode Warning: Failed to attach to wpa_supplicant. Could not connect to wpa_supplicant: wlo1 - re-trying Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. ^Celoop: could not process SIGINT or SIGTERM in two seconds. Looks like there is a bug that ends up in a busy loop that prevents clean shutdown. Killing program forcefully. -------------------------8<------------------END------------------->8----------- 5.) Using strace on both programs revealed a similar socket based communication what I have seen between dhcpcd-gtk and wpa_supplicant The interesting part comes below from wpa_supplicant -------------------------8<----------------BEGIN------------------->8----------- recvfrom(11<socket:[2490509]>, "ATTACH", 8193, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_346236-2"}, [128->25]) = 6 getsockopt(11<socket:[2490509]>, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(11<socket:[2490509]>, TIOCOUTQ, [0]) = 0 sendto(11<socket:[2490509]>, "OK\n", 3, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_346236-2"}, 25) = -1 ENOENT (No such file or directory) -------------------------8<------------------END------------------->8----------- See the file not found error in the last line. However that file does exist in my /tmp !! -------------------------8<----------------BEGIN------------------->8----------- pasja@bifrost ~ % l /tmp/wpa_ctrl_346236-2 srwxr-xr-x 1 root root 0 Feb 7 18:49 /tmp/wpa_ctrl_346236-2 -------------------------8<------------------END------------------->8----------- 6.) My understanding was partial at that time, so I went back and checked what Privatetmp does exactly, and it turned out that it creates a new mount namespace. With `systemd-cgls` I was able to confirm that both wpa_supplicant and dhcpcd are living in the same namespace -------------------------8<----------------BEGIN------------------->8----------- pasja@bifrost ~ % systemd-cgls Control group /: -.slice [redacted output] ├─dhcpcd.service (#15832) │ → user.invocation_id: fb283568273843dbb14259f938137d6a │ ├─298963 dhcpcd: [manager] [ip4] [ip6] │ ├─298964 dhcpcd: [privileged proxy] │ ├─298965 dhcpcd: [network proxy] │ ├─298966 dhcpcd: [control proxy] │ ├─298984 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant-wlo1.conf -iwlo1 │ ├─310014 dhcpcd: [BPF ARP] wlo1 192.168.9.182 │ └─310585 dhcpcd: [BPF ARP] enxc03ebac7d8c3 192.168.10.248 -------------------------8<------------------END------------------->8----------- 7.) The final step was that I have compared the mountinfo in the working and the non-working case for wpa_supplicant and see that in the non-working case /tmp does get an extra mount from the Privatetmp config -------------------------8<----------------BEGIN------------------->8----------- root@bifrost /tmp # cat /proc/$(pidof wpa_supplicant)/mountinfo | grep '/tmp' 365 349 254:1 /tmp/systemd-private-6fcbcdab04764cda9a462c45fdeb8c4c-dhcpcd.service-sEjoOg/tmp /tmp rw,relatime shared:332 master:1 - xfs /dev/mapper/bifrostfs-root rw,attr2,inode64,logbufs=8,logbsize=32k,noquota 461 349 254:1 /var/tmp/systemd-private-6fcbcdab04764cda9a462c45fdeb8c4c-dhcpcd.service-9mlKoh/tmp /var/tmp rw,relatime shared:369 master:1 - xfs /dev/mapper/bifrostfs-root rw,attr2,inode64,logbufs=8,logbsize=32k,noquota -------------------------8<------------------END------------------->8----------- Now that explains why wpa_supplicant can communicate over its socket and says that the file is not found. I think with that we have reached a conclusion. Without a major refactor in both wpa_supplicant and dhcpcd this will not work. Our options are the following I think: a.) leave out Privatetmp from the unit file b.) leave in Privatetmp from the unit file and document down that one has to start wpa_supplicant via different means, e.g.: as a separate systemd unit I can live with either of the options, have no strong preference. In the end we have managed to keep much of the hardening in place, which is a good this as dhcpcd is a bunch of C code which parses untrusted input from the network, and I am graceful for the extra safety net what systemd provides. Regards, János Pásztor
