KDE6 release: D-Bus and Polkit Galore (SUSE security team blog)

As a Gentooer I can of course toggle features such as polkit at build time via USE flags. Given that I never wanted to take the time to understand polkit's configuration to the point I could be fully comfortable using it in its designated security context, USE=-policykit and no polkit on my system! Which is for the most part just fine since most polkit usage is GUI authentication and I have a policy of no root gui, all system level operations are done at the CLI (or TUI such as mc and htop), meaning I have little use for polkit.

Also, CLI login and run a plasma-wayland session from there, no *DDM graphical login installed. (And a lot of other "bloat" like semantic-desktop and pipewire USE-disabled and not installed, as well. )

But the kauth/kwalletmanager polkit integration and "fake security" described in TFA is "interesting" in the context of a non-existent polkit. IIRC it was the early kde5 era when I decided I needed some kwallet config changes, only to discover that without polkit the kwalletmanager GUI was effectively read-only -- despite the settings being user-level not system-level!

Turned out that kwallet stored its settings in an unencrypted text rcfile (kwalletrc IIRC), owned by my normal user/group, but I couldn't GUI-edit the settings despite seeing them there, and had to text-edit the rcfile instead. Of course that meant some digging around to figure out the exact significance of a number of the key=value ini-style lines, because some of them didn't quite correspond to the descriptions in the GUI.

But I distinctly remember how odd and frustrating it was to me, to have the GUI insist I wasn't authenticated to operate on a text-based config file owned by the same user/group that the app was running as and that it had originally written -- tho likely back in the kde3 (pre-polkit!) or kde4 era, presumably before it required that fake authentication to operate on something it owned in any case!

Seems the SUSE security team find it odd too, even when they /are/ running polkit!

One would /think/ such settings, if not considered appropriate for the user to edit without authentication, would have XDG-specified handling much like per-user tmpdir settings, maybe something in /etc/usersec/$user/ (or $UID?) that an as-root polkit-authenticated daemon could write to on behalf of the user, such that the file would be in a per-user dir but not /owned/ by the user. Either that or just let the user edit the settings in the GUI that they could edit in a texteditor anyway, since they own the file and have permissions to the path it's in.