The great irritation of hidden access controls

June 28, 2010

One of the things that I really hate about modern desktop environments, specifically their graphical system administration tools, is that they are increasingly completely hiding their access controls and authorization systems. I know that they have them, because they have some mechanism for doing various operations that require root permissions without bothering to ask me for the root password. But it's become just about impossible to find them; what was once at least visible in PAM configurations has vanished into what I believe is a twisty mess of Kits (PackageKit, PolicyKit, whatever) and DBus-based agents.

(The most flagrant recent example of this is my Fedora 13 machine, which will happily let me click buttons to apply package updates without ever asking me for the root password or giving me any way to control this. Where this is controlled is undocumented and opaque, as far as I can tell. Perhaps the system will just permit all console users to do this, or perhaps I accidentally clicked on a button to tell it to remember this permission permanently. Fortunately I am not trying to run a lab full of Fedora 13 machines, or this really would be hell.)

I'm reasonably sure that all of this is perfectly transparent if you are an expert who works in this area all of the time (and hopefully there are magic controls somewhere). I'm equally sure that it's completely opaque if you are not, and that's a problem.

One of its irritations is that I wind up feeling that I'm not in control of my system, which is not something that I'm accustomed to on a Unix machine. Unix systems are not supposed to be mysterious black boxes where things just happen for your own good (or just because), controlled by distant developers and system creators; they are supposed to be systems where you can follow everything that is going on. The 'we know best' complex, opaque world is the world of Windows, and I am not enthused about Unix becoming Windows.

(This view of Unix is starting to be a trend.)

Sadly, part of the problem is DBus, which has become the great nexus of spooky privileged action at a distance on modern Linux machines. In the old world, even the world of heavily PAM-ified magic authorization, you could at least follow the path of setuid binaries (and what ran them) to work out what was going on. In the new DBus world, setuid is no longer required; all you need is the right DBus system agents that programs can talk to, and magic happens.

(Sometimes the magic is even documented, but don't hold your breath on that. These things are not intended to be user-accessible parts, so they seem to get about the documentation you'd expect. And in this, sysadmins pretty much count as ordinary users.)


Comments on this page:

From 194.72.135.18 at 2010-06-28 05:03:41:

Oh, I so agree. The amount of HAL/dbus/Avahi FreeDesktop-related STUFF that has been crammed into Fedora in the last few years puts it a long way from the basic, understandable X-based systems I started on twenty years ago. Sure, the desktop looks and behaves in a more sophisticated (more "Windowsy") manner. It's also near-impossible to wrap your head around how it all works, particularly when it goes wrong. (And it will go wrong; it always goes wrong eventually.) As you say, the lack of canonical documentation is a particular frustration.

Ade

From 65.172.155.230 at 2010-06-28 10:24:14:

The best documentation I know about is due to the "allow any user to install a package" snafu ...

http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/

...applying this to updates should be "easy", or just "yum remove PackageKit" :).

Written on 28 June 2010.
« How we propagate password information in our fileserver infrastructure
There is such a thing as too much SQL (a reminder to myself) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jun 28 01:01:17 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.