Configure kdesu for "Run as Different User" to Never Require a Password

[Duncan]

Richard Hajek posted on Sat, 9 Nov 2024 13:10:25 +0100 as excerpted:

> Hello!
> 
> I’m trying to configure `kdesu` so that the "Run as Different User"
> option in application menus never prompts for a password - not even on
> the first use. I’d like to run certain applications as a different user
> without needing to input any password.
> 
> I’m aware of the security implications of this setup, but I’m already
> running `sudo` without a password, so security isn’t my primary concern
> here. After looking through the `kdesu` source code, I couldn’t find any
> configuration files or settings that might enable this behavior. The
> only plausible way how I imagine it could work would be to have a script
> start kdesu and send the credentials before starting the other app but
> that seems unwieldy.
> 
> Has anyone managed to achieve this password-free setup with kdesu, or
> know of a workaround to make it happen?
> 
> Thanks for any help or insights!

So it's possible someone with more direct knowledge will post a more 
directly helpful reply, but in the absence of that...

FWIW, my policy here is no GUI as-superuser/other-user; I only allow that 
via CLI, so no kdesu here. (FWIW on gentoo/kde it's supposedly a runtime 
dep of something or other I have installed, but I went to the lengths of 
installing a stub-package containing nothing but filling the runtime-dep, 
to avoid it.)  And also no policykit or similar system-level solution, for 
similar reasons, so I'm not sure how the particulars of the below would 
work, but maybe it'll start you in a useful direction, regardless...

Normally, for Linux-style GUI super-user/other-user access, policykit is 
used (invoked via dbus), and its configuration determines whether and 
under what conditions a password is required.  (And it was partly a 
discomfort with my ability to be confident I had sufficiently mastered 
that config to the degree that I could be confident in my security 
posture, that lead to a simpler policy of just banning such functionality 
at the GUI level.)

It follows that, assuming kdesu is implemented via policy-kit (which I 
believe it is these days, tho it wasn't back in the day... either that or 
there's a similar-functionality tool by another name that does so), kdesu 
probably doesn't need to deal with configuring whether and under what 
conditions a password is required, because that's very likely 
functionality provided by the underlying policy-kit and its configuration.

So where I looking for a GUI solution, I'd approach the problem by 
confirming that kdesu does indeed use policykit, finding the alternative 
that does if it doesn't, and then researching policykit configuration, as 
that's where I believe the solution to be.

That said, what I've actually done (I don't expect this to be a viable 
solution for you, but it's what works for me), in addition to policy-
banning "as super/other-user" functionality at the GUI level as I already 
mentioned, is configure a "sysadmin-hat" user, in addition to my "user-
hat" user.  User-hat user gets GUI privs, but not, as itself, admin-hat 
privs.  Admin-hat user gets passwordless superuser sudo privs, but not GUI 
privs.  User-hat user gets, supplying its password, access to login as 
admin-hat via sudo, plus access to a few other directly specified sudo 
commands, some with password, most without as I'm /reasonably/ confident 
those nailed-down commands shouldn't be abusable to escalate to 
unrestricted superuser.

So for most admin-user tasks from the user-hat user, I open a konsole and 
sudo (via script) to the admin-hat user, supplying the password to do so.  
Then as admin-hat user I can passwordless sudo whatever CLI/TUI commands I 
need to do from the admin-hat konsole session.  There's a limited number 
of other things the user-hat user can do via sudo, but none involve a GUI 
(most are in fact designed to be invoked via script, or are 
troubleshooting commands like tcptraceroute) and they are deliberately 
limited, because the big one, for which a password is /definitely/ 
required, is simply the ability to sudo to admin-hat user.

In the event sudo is broken I do have direct su ability as well, or worse-
case, I can direct CLI login (no GUI login either... as /any/ user, I CLI 
login as user-hat user and start the plasma-wayland GUI from there) as 
root, either normally or via systemd emergency/rescue mode, or direct 
init=/bin/bash from grub, or /worst/-case if it's /all/ broken I can boot 
one of my backups (a snapshot of the fully functional system at the time 
of the backup) and use it to do whatever I need to to recover a normal 
working system on my normal working partition.  But normally, if it's an 
admin task, it's sudo to admin-hat user, and do whatever in the TUI or CLI 
from there.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman