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
