Raghav Gururajan via Guix-patches via schreef op vr 18-06-2021 om 02:54 [-0400]: > +;;; > +;;; Bitmask VPN > +;;; > + > +(define-public bitmask-service-type > + (service-type > + (name 'bitmask) > + (description "Setup the @uref{https://bitmask.net, Bitmask} VPN application.") > + (default-value bitmask) > + (extensions > + (list > + ;; To configure polkit policy of bitmask. > + (service-extension polkit-service-type list) > + ;; To add bitmask to the system profile. > + (service-extension profile-service-type list))))) Is there any specific reason that bitmask must be added to the profile? On a multi-user system, not all users might be interested in bitmask, and do not need it in their "PATH". I prefer only adding packages that are explicitely in the ‘packages’ field of 'operating-system' to the system profile. One possible reason could be that the polkit policy whitelists a few binaries, say, /gnu/store/aaa-bitmask/sbin/stuff, so "pkexec stuff" (equivalent to "pkexec /gnu/store/aaa-bitmask/sbin/stuff") doesn't require special permissions or a password of any kind. However, if the user has a slightly different version of bitmask in their profile, then the store path will be different (/gnu/store/bbb-bitmask/sbin/stuff), then "pkexec stuff" will try to use the not-authorised version, which will require passwords or such. For example, my current system generation and user profile were made by a different version of Guix, and as a result, have two separate store paths for "mate-power-backlight-helper". If I run pkexec on the store path in /run/current-system/etc/polkit-1/actions/org.mate.power.policy, then it succeeds. But if I simply run "pkexec mate-power-backlight-helper", then it asks for authentication. (Actually, /run/current-system/profile/sbin/mate-power-backlight-helper points to a binary with yet another store path, but that has nothing to do with bitmask-service-type.) (TODO to self: modify "pkexec" to support an --action-id argument, in order to avoid store paths ...) Greetings, Maxime.