pam.d and polkit strike again

I hate pam.d (system level), and polkit (group level). Both cause interaction problems and are parts of a larger failure of Linux progression over the years: what users previously configured in a few quick text changes in their /etc folder (most of the original appeal of Linux, in other words) have become memory hogging daemons. These applications each seem to have a specific syntax inside a (difficult to locate) configuration file, and handshake issues. For example, group and user policy overlord polkit runs multiple threads and hogs memory for zero benefit. Here's a few solutions to pam.d and polkit issues I encounter. BTW, gconf is nearly as disgusting.

disable polkit

Disabling pam.d will break your session because so many app writers have caved to its policies, but disabling polkit just means, eg. entering $ udiskie & when mounting a USB drive. Best solution:

# systemctl stop polkit
# systemctl disable polkit.service

The above worked and freed-up some percentage of CPU cycles and about 50M of RAM. None of what was described here worked -- either creating the following file in /etc/polkit-1/rules.d/99-deny-all.rules

polkit.addRule(function(action, subject) {
return polkit.Result.YES;
});

... or using $ startx --vt7.

authorization levels

Most old-time Linux users configuring access authority between users, groups, and applications expect simple, fast, text editor options in /etc/sudoers, and maybe /etc/group files. Not since the abomination pam.d was developed. One still must accomplish, say, /etc/sudoers changes in the old syntax. But, as noted well in this post, more complicated work is necessary in pam.d as well.