how to disable PolicyKit?

[Oron Peled]

I reordered the topics...

On Thursday, 29 בOctober 2009 00:10:54 Oleg Goldshmidt wrote:
> Does anyone know how I can disable the bloody thing globally so that
> it shuts up once and for all? I am wary of uninstalling it bluntly
> after I tried to trace the RPM dependencies and got lost in the forest
> - the dependency net is cast widely indeed. Is it safe to "rpm -e
> --nodeps"? Will anything serious break? 

1. Obviously. The dependencies are not there just for kicks. If you try
   to run:
        yum remove PolicyKit
   You'll see that if you approve (don't) it will remove most of the system.

2. It is pretty integrated with modern Linux distributions, as it is
   part of the new Linux "plumbing", together with udev, dbus,
   hal (migrating to DeviceKit), NetworkManager and other *Kit thingies.

> It seems to be a complicated and cumbersome authentication/security
> framework that so far has not done me much harm (I think), but I blame
> it for popping up annoying and meaningless (to me) "authorization
> dialog" forms requiring username and password for all kinds of weird
> things, URLs, etc. http://scripts.felloweb.com comes to mind as one
> of the recent ones,

3. Not all authentication/authorization pop ups belong to PolicyKit.
   First check you are not blaming it for some other pop up generator.
   Some examples from the top of my head:
   * Firefox - to control access to web sites passwords.
   * kwallet - to control personal passwords for all
     KDE related apps (konqueror web site passwords, kopete, kmail etc.)
   * gnome-keyring - ditto, for GNOME apps.
   * gpg-agent (via pinentry) - for access to gpg private keys.
   * ssh-agent - for the ssh private keys (or you may configure
      gpg-agent to work for ssh as well...)

Note: Obviously, it would be nice to unite them all together, but it's not
          trivial -- who is going to implement WalletKit ;-)

4. Before PolicyKit, different distros/desktops implemented workarounds
   for running privileged operations from the desktop. Examples:
   - kdesu from the KDE folks.
   - Something from gnome (forgot its name).
   - The venerable sudo.
   - Some pam tricks (used by Fedora) to enable selected GUI administrative
      programs to be run by a normal desktop user, after entering a password.

Note that all these mechanisms also ask for passwords...

> and for the life of me I can't figure
> out why, on top of sudo, pam, SElinux, and everything else I need this
> thing from the fscking Gnome (pardon my French - I don't even use
> Gnome, but there is PolicyKit-kde as well).

5. First, there's more than one way to do it ;-)

6. The only overlap I see is with the old tricks mentioned in 4. which will
   gradually phase out as PolicyKit support enters more applications.
   All others serve totally different needs.

7. PolicyKit is about delegation of control:
   - In the old days, we only used su/sudo/other-suid-program for this.
   - But we don't want to run whole dekstop application as root
      (think about running network configuration GUI as root. How
      many buffer overflows are hiding in the whole GUI stack?)
   - So split architectures started to emerge (e.g: NetworkManager).
      A non-privileged GUI (e.g: nm-applet) talks to a privileged
      system service (NetworkManager itself).
   - PolicyKit provide a uniform desktop independent API to such
      application writers that so they know which client requests to
      respect and which to deny.
      It also provides a central control mechanism for administrators.

> What I really want to do is to kill the beast once and for all.

Too late, it already escaped the cage some years ago ;-)

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
First we take Manhattan , then we take Berlin...(Leonard Cohen).
Linux and Open Source - The Revolution of Choice