polkit (formerly Policy Kit) provides two important services.
From the project documentation:
an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“SUBJECTS”) often through some form of inter-process communication mechanism.
...and...
allows users to obtain temporary authorization through authenticating either an administrative user or the owner of the session the client belongs to.
The first provides a safe way for user-level applications to ask for root-level actions. You might use this regularly without noticing in Desktop systems -- like suspending, or mounting newly-inserted hardware. Polkit is part of that mysterious glue that makes the desktop work.
The second is (most commonly) the GUI "admin privileges are required for this actions" dialog.
polkit is a necessary element in all Ubuntu Desktop (GUI) systems. Removing polkit will destroy your Ubuntu Desktop (GUI) system. It's generally not needed if you run headless (without GUI / Ubuntu Server), though folks do sometimes add software that needs polkit.
Answer from user535733 on askubuntu.compolkit rule to enable/disable specific systemd service without password
The journey of purging polkit from your system on Gentoo
Optional Feature: --disable-polkit
Can i disable "polkit.service"?
Update
Redhat have changed the RPM dependencies around Polkit. It can now be uninstalled from servers even if something had pulled it in during prior upgrades or installations.
I am now able to uninstall Polkit from servers that other folks built as of CentOS 7.6.
It is still required on Workstations and that appears to be appropriate for desktop usage.
After adding rules to /etc/polkit-1/rules.d/99-deny-all.rules you should restart polkit service by systemctl restart polkit. After this systemctl would execute any requests from non-priveleged user.
I would like to create a polkit rule that allows a specific user to enable/disable a specific service (or alternatively just run it only on the next boot, but I think that would be more complicated) without being prompted for a password. I have a rule to allow the running/stopping of a service, but I can't seem to get the same for enabling/disabling right, so I am hoping someone here can help me.
I managed to get it to allow the user to enable/disable any service by checking action.id against org.freedesktop.systemd1.manage-unit-files, but action.lookup("unit") doesn't work in that case, so I can't check that way if it's the right service and allowing the user to manage all units without authentification seems excessive.
Also I am aware using sudo/doas would be an option, but if possible I would prefer the polkit solution.
Okay, so, I decided to remove any trace of polkit from my system. Why? Because I never used it and that's what Gentoo is for. I'm not sure why I ever had it on my system, probably because the profile I choose at the start includes it. I honestly cannot recall ever doing something that requires access outside my home dir without elevating privileges so why not remove it? Well, turns out it's pretty hard to remove polkit to the point that repeated "This is BS" went through my mind attempting to do so. Did you know that it took me three recompiles of Wine to remove polkit? Yeah.
So, obviously, the simplest way to start is to remove the USE flag "policykit" from my global use flags and do a world update and see what happens. For those who don't know. USE flags are Gentoo's system of enabling parts of programs, one of the big reasons it's a source distro. Basically you instruct programs to no longer by default offer support for polkit, a world update then activates the necessary changes.
So about 8 packages get recompiled, about 8 outright get removed. That's nice isn't it, Gentoo's dependency system is flexible enough for packages to depend on other packages only if certain USE flags are turned on. So I thought "Well, this is easy", well, not really, turns out that one of the things that did not get removed was polkit itself, it's still there.
So, I check what stuff depends on polkit. One of them was pulseaudio, at this point I was ready to admit defeat. I could understand that pulseaudio depended on polkit and it used it to access the hardware or something. But no, this wasn't true, because Gentoo is awesome, turns out pulseuadio only depended on Polkit when Wine had a specific flag set. Yes, Portage's dependency system is flexible enough to let package X depend on package Y only if package Z has a specific flag set where Z does not depend on X. This is why resolving dependencies on Portage takes forever.
So, I removed that flag 'realtime' and recompiled wine and furthered my search. That recompilation of wine took quite some time actually and I regret that because I'm an idiot. Turns out there were two more flags with a similar relationship and I recompiled it two times fruther for those two while I could've done it in one time.
Next up was a pretty interesting and bizarre circular dependency. Basically, consolekit depends on polkit when consolekit has the USE flag "polkit" on. Okay, that seems reasonable. But when that flag is on, then polkit depends on consolekit or systemd. Does that make any sense? Well, it means a circular dependency is created the moment you install consolekit with polkit support. I later found out that Portage can easily delete two packages which circularly depend on each other by just asking to remove them within one command. The way I resolved it at the time was some "know what you are doing" tomfoolry by overriding the safety checks and unmegring the package even though polkit depended on it.
Next up was udisks which required polkit, this is just some dumb daemon that allows automatic mounting of external drives. A policy I am vehemently against. You should always elevate privileges I feel when you connect an external drive, So boom, that was gone, didn't even know I had it.
And finally. I have a system without polkit and consolekit that seems to work perfectly well.
So what if there weren't any USE flags, what if you ran a binary distro. Would you seriously then be required to have polkit installed just to run Kate or Wine without being able to compile that functionality out of it? Not sure but it seems to me that you would.
You can use the same technique Ubuntu's Live CD uses by tricking PolicyKit and suppressing ALL password prompts by substituting the action with a wildcard.
DISCLAIMER: The following will suppress ALL password prompts globally for everyone belonging to the admin group, with the exception of the login screen. It is EXTREMELY dangerous and should NEVER be implemented because chances are YOU WILL END UP BREAKING YOUR SYSTEM!!
Don't say you weren't warned!
NOTE: If you are running 12.04 or later, substitute "admin" with "sudo"!
Replace "username" with your actual user name:
usermod -aG admin username
Switch to root:
sudo -i
Create a new policy:
gedit /var/lib/polkit-1/localauthority/50-local.d/disable-passwords.pkla
Add the following:
[Do anything you want]
Identity=unix-group:admin
Action=*
ResultActive=yes
Save and exit. Then go try something that usually requires a password. :)
NOTE: It doesn't matter what you use as your .pkla file name. You can name it anything you want.
And last, this is the ONLY policy you'll need when it comes to suppressing password prompts because again, it does so globally.
You can create a .pkla, either an all in one or a couple based on action groups, doesn't really matter.
For reference look in /usr/share/polkit-1/actions, open interested ones in a text editor to get action id's.
As far as a .pkla or 2 I find the best place to put them is here, it will be protected from any updates
/var/lib/polkit-1/localauthority/50-local.d
So for example here is my main one, named package-manager.pkla though it extends a bit further than just package management policy's
[Install package file]
Identity=unix-group:admin
Action=org.debian.apt.install-file;org.debian.apt.update-cache;org.debian.apt.install-or-remove-packages;org.debian.apt.upgrade-packages
ResultActive=yes
[Install package synaptic]
Identity=unix-group:admin
Action=com.ubuntu.pkexec.synaptic
ResultActive=yes
[Change add repo]
Identity=unix-group:admin
Action=com.ubuntu.softwareproperties.applychanges;org.debian.apt.change-repository
ResultActive=yes
[usbcreator format]
Identity=unix-group:admin
Action=com.ubuntu.usbcreator.format
ResultActive=yes
[Install bootloader]
Identity=unix-group:admin
Action=com.ubuntu.usbcreator.bootloader
ResultActive=yes
[Add users]
Identity=unix-group:admin
Action=org.freedesktop.accounts.user-administration
ResultActive=yes
Note that starting in 12.04 the group used for "admin" user should be changed to sudo, ie.
Identity=unix-group:sudo
Also note that actions can be strung together per section, no spaces, use a ; in between id's