Whenever there is an update, I’m forced to enter a password in Discover. Other things (such as KDE Partition Manager) also demand me to enter the password before using it.
But the computer is already unlocked, so this doesn’t make sense to me as a security measure. How do I turn it off?
This looks extremely sketchy. This can’t be the right way, can it? Why does it want me to make some script? Why isn’t it an on/off option? This is in Debian, BTW, but why would it have anything to do with the distro rather than KDE Plasma?
It’s as if they want to “discourage” this by making it cryptic and weird. Why?
for some updates and whenever you do operations on disk partitions, you need to have root access.
your login only gets you to your user acct… i believe (but not tried this) that you can set your root password to be different than your user password, if that helps you.
it’s not recommended to log in as root because that protects the system from user screw ups and typos… it’s basically the same as “run as administrator” in windows.
the KDE partition manager doesn’t need root to SHOW you how the drives are laid out tho, and that part is annoying… gparted does the same thing
see if your repository offers disks to use as an alternative… it only prompts you for the root password when you actually go to modify something that requires root privilege.
But I have to use “Discover” far more frequently than doing partition stuff. Every day, basically, when there’s an update or more.
To answer this question I need your OS.
These GUI password dialogs are caused by “polkit”. Try pkexec echo hello.
In KDE there is a nice option how to get the polkit action that requires the password.
If you click on “Details” you can see the programs name.
For this exact purpose I created a little script, polkit-helper
Examples of some rules in my /etc/polkit-1/rules.d/
$ cat kdepartitionmgr.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.kde.kpmcore.externalcommand.init" && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
$ cat org.freedesktop.udisks2.open-device.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.open-device" && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
$ cat 80-udisks2-encrypted-unlock.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.encrypted-unlock-system" && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
$ cat 80-udisks2-encrypted-unlock.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.encrypted-unlock-system" && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
➤ cat 80-libvirt-manage.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage" && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
➤ cat firewall.rules
polkit.addRule(function(action, subject) {
if (action.id == "org.fedoraproject.FirewallD1.all" && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
Your distro may have another action ID for the updates, and I agree they should be automatic and without any password. A weird linux thing, that updates should be manual and require a password. My rpm-ostree rules look like this:
➤ cat org.projectatomic.rpmostree1.rules
polkit.addRule(function(action, subject) {
if ((action.id == "org.projectatomic.rpmostree1.repo-refresh" ||
action.id == "org.projectatomic.rpmostree1.upgrade") &&
subject.active == true &&
subject.local == true) {
return polkit.Result.YES;
}
if ((action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.bootconfig" ||
action.id == "org.projectatomic.rpmostree1.reload-daemon" ||
action.id == "org.projectatomic.rpmostree1.cancel" ||
action.id == "org.projectatomic.rpmostree1.cleanup" ||
action.id == "org.projectatomic.rpmostree1.client-management") &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
This is a little more complex but shows these things:
groupadd updates
sudo usermod -aG updates $USER
# adapt the update rule
On most single-user systems its best to allow updates for wheel and call it a day. But in my opinion every user should be able to update, and nothing else.
yeah this may be a little much, even though if you say “my PC my choice” and also “if anyone can access my PC, I have bigger problems than random installed packages”
For most people the sensible data is in home, so sudo is not really important.
But it may be best to have weird sudo tasks still behind a password, so that they dont all auto-run, which would make malware execution VERY easy. So no, dont use that Arch guide
whenever discover needs to update something with root privileges, it will prompt you for the root password (for you probably the same as your login password).
installing the flatpak version of software seems to avoid the need for root passwords when they update, so keep that in mind when choosing the format of your software installs.
not much you can do about the OS side of things or snaps (if you have them) except, as i said, change your root password to something easier to type.
also you can set your update frequency in discover so you don’t have to interact with discover but once a week or whatever.
Yeah, Windows once created all users with admin (root) privileges and witness how content their users are, and how they NEVER compromise their systems. D’oh! :-J
not true. Modern Distros use Polkit, and (dont know under which circumstances) you can set what actions dont require a password for what user in what group in what condition.
Let’s not call that a “root password”. Similarly to sudo, it’s asking for your password. The original meaning for this action is the following: dear user, you’ve requested a root operation, is it still you behind the keyboard, not some random passer-by in your office? Give me your password now.
Yes, the overall UX of this might be questionable these days. I guess it’s more from the times when you were literally sharing a machine with 100 other users, and tried to update software or repartition the drive 
But still you’re getting similar experiences in other places: mobile phones requesting PINs again for some sensitive settings screens, web sites asking for password again if you try changing your password, etc.
To my taste this is not overly irritating. I don’t repartition drives every day. I don’t update the software every day either, on Debian I don’t even use Discover for that (you can see a separate topic as for why ). If you update frequently and would really like to lower your involvement in this, maybe consider unattended-upgrades? It might be better addressing your needs than trying to make Discover not ask for the password, but still clicking through it every day yourself.
With unattended-upgrades, there are other risks and considerations, though.
The question simply is: Do I simply use my lockscreen if I want nobody to access any private data?
This is a way better option for me. Another danger actually, of entering your password, can be that you enter that password you rely on when screenlocking, so people can see it more easily.
Why would updates be blocked? Updates are crucial and especially security updates should run automatically.
On an atomic system like Kinoite its more clear: You trust the origin of your software updates. So any user could update the software without any danger to your security. A user should not be able to “deploy random systems”, rollback updates (maybe important security fixes), pause updates, exit updates etc.
So this is the threat model. And also:
So why should updates harm your system, but any person looking at your files, sending them over the internet, reading your mails and messages, etc. not be a problem?
On Linux for some reason we dont really have per-action authentification, which could be improved. Maybe Flatpaks could deal with that?
Probably because KDE developers don’t expect users to turn it off.
As others already pointed out, the most valuable data on your PC is in your home directory, so your argument indeed makes some sense, and probably protecting root doesn’t matter that much now. But it’s a long Unix tradition, not easy to break.
It’s not. Just it’s intended for software developers, not end users to use.
It has nothing to do with the distro. Arch as a (minimalistic) distro has very few distro-specific things, so most of ArchWiki applies to all distros, and it often come up at the top of google search results.
If you scroll down just a few lines in that Arch guide, you’ll see it suggests exactly the same rules as yours.
the admin access restriction is not there to protect your privacy… it’s there to protect the OS from user contamination.
I am curious, does it also restrict malware from executing anything? I mean this malware would already most often have full home access etc, but anways, I was never sure about this. I guess it does, right?
Try this:
sudo cat > /etc/polkit-1/rules.d/allow-apt-packagekit.rules <<EOF
polkit.addRule(function(action, subject) {
// Check if the action is related to apt or PackageKit
if ((action.id.indexOf("org.debian.apt.") === 0 || action.id.indexOf("org.freedesktop.packagekit.") === 0) && subject.local && subject.active && subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
EOF
This allows wheel (when local and active) to do all apt and polkit tasks. It is a pretty broad rule though and you might only want to allow updates.
There is one important difference though. Mobile apps can’t do much if they manage to steal your PIN (unless they have special permissions like a11y). Web sites are confined within the browser frame, making it difficult to disguise.
But it would be trivial for a malware to pop up a fake KDE polkit dialog, and the user probably will happily enter the password. And sudo has the same problem.
Does Polkit support prompting for evaluation without the user’s password like User Account Control in Windows?
In this instance, it would serve as confirmation before running anything with evaluation without repeated requests for a password.
Yes you can.
Your /etc/pam.d/polkit-1 probably looks like this:
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
Now you need to replace the auth line, so the file ends up like this:
#%PAM-1.0
#auth include system-auth
auth optional pam_unix.so
auth sufficient pam_permit.so
account include system-auth
password include system-auth
session include system-auth
I.e. we still ask for a password, but the authentication succeeds even with a wrong one.
Now you can just press enter when the polkit dialog pops up.
(BTW, if you delete the auth optional pam_unix.so line, the dialog doesn’t show at all.)
Of course this is just a horrible hack. Please don’t use it. Perhaps KDE polkit agent can gain a “don’t ask again” checkbox (and a KCM to revoke remembered auths).
mine does not look like that at all
#%PAM-1.0
@include common-auth
@include common-account
@include common-password
session required pam_env.so readenv=1 user_readenv=0
session required pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-session-noninteractive
i would not mess with this on my system without a backup plan.
Just change the auth line. And this file only affects the polkit dialog. Your sudo and su will be ok. The backup plan is just changing it back.