wpa_supplicant: introduce unprivileged service

[dkwo]

This is the same setup that was proposed earlier, except we now create a new service, so the user can choose what to use (default to current root service). The unprivileged service has been working seamlessly for me for many months, but certain setups can be affected, e.g. wpa_cli (see also the discussion in nixpkgs).

See also the corresponging pr for dhcpcd #53404

[classabbyamp]

what discussion in nixpkgs?

[Duncaen]

Just fully changing the ownership of the configuration directory to the writable by the unprivileged user does not seem like its necessary.

[dkwo]

Refs: NixOS/nixpkgs#305722 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031375

Would chown -R _wpas:_wpas /etc/wpa_supplicant/* be better? if so, I can test it.
The reason is that there can be other files there, such as a password file (via ext_password_backend) or wifi certificates.

[Duncaen]

Maybe something like root:_wpas and make sure its only owner writable?

[dkwo]

Indeed, this seems to be enough:

$ ls -la /etc/wpa_supplicant 
total 20
drwxr-xr-x  2 root root  4096 Jun 14 19:38 .
drwxr-xr-x 60 root root  4096 Jun 14 19:46 ..
-rw-r-----  1 root _wpas 2094 Oct 12  2022 eduroam.cer
-rw-r-----  1 root _wpas  215 Nov 14  2024 wifi-passwords.conf
-rw-r-----  1 root _wpas  800 Feb 23 15:37 wpa_supplicant.conf

I changed the service accordingly.
At this point, the user only needs to change control_interface_group to _wpas in the conf file to use the unprivileged service.
Does this warrant an install msg?

[dkwo]

After some trial and error, I found out that I can even lockdown the file system, giving it only access to

  --landlock-access fs \
  --landlock-rule path-beneath:read-file:/proc/sys/net \
  --landlock-rule path-beneath:read-file:/dev/urandom \
  --landlock-rule path-beneath:read-file:/etc/group \
  --landlock-rule path-beneath:read-file:/etc/wpa_supplicant \
  --landlock-rule path-beneath:read-file,execute:/usr/bin/wpa_supplicant \
  --landlock-rule path-beneath:read-file,execute:/usr/lib \
  --landlock-rule path-beneath:read-file,read-dir,remove-dir,remove-file,make-sock:/run/wpa_supplicant \

Would it make sense to add this to the unprivileged service?

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.

[ahesford]

Adding a competing service is bad UX. It creates confusion about when to use one or the other, and guarantees that at least one service is never going to be used on each installation.

A service that forcibly modifies permissions or ownership of configuration files is terrible UX. No service should ever change these properties unless it only does so while creating them.

Either 1) this change is worth making, and we dice a migration with a single service; or 2) the existing single service can provide a configurable option to run as an unprivileged user.

[dkwo]

There is a bug in wpa_cli that prevents it from communicating with the daemon, if this is running as non-root: I think we should patch it, by removing the corresponding ifdef android.
If we use a single service (as I had proposed initially), the permission changes to /etc can be done at post-install stage, but /run must be created in the runit service, or chowned if it already exists, unless we tell the user to do it by hand once upon updating. (The user must also change the control_group by hand in conf.)
I will push these changes soon for review.

[dkwo]

I imported a patch from nixpkgs, which makes wpa_cli work.
Note the 750 in install -m 0750 -g _wpas -o _wpas -d /run/wpa_supplicant.

[ahesford]

These changes are not acceptable for several reasons:

• Moving the ownership and permissions changes of /etc/wpa_supplicant to a post-install script don't fix the terrible UX. Packages should never change the ownership or permissions of user-configurable files like this. We can never know the user's intent when permissions are not what we expect.
• Pulling an arbitrary patch from NixOS is not really appropriate. Find a commit merged upstream, and use a git-formatted patch that shows its provenance.
• The patch is wrong regardless of its source because it hardcodes the group.
• Requiring the user to change permissions on a /run directory and its contents is error prone and bad UX. Let's try to find a more elegant way to handle this transition.

[dkwo]

The patch is not upstream. Alternatively, I tested that running (umask 0 && wpa_cli) works: maybe this is better?
I am open to suggestions how to deal elegantly with /etc and /run changes.