I wrote some time ago about how most modern Linux distributions deals with with granting unprivileged users additional privileges when they are logged in at the console. Stuff like allowing them to access removable disks, power down the system and so forth - Project Utopia stuff, that whole story.
While this is great for the home user, stuff Just Works, it’s not always ideal in more controlled environments such as call centers, university settings, Internet Cafes or print kiosks. Also, working for a distributor I’m also sometimes personally on the receiving end of rude people who wants this too. I don’t disagree much really. Yes, it makes sense to easily lock down what the operating system allows a user in front of it to do. Even to the point where it is totally unusable. Notably this is required for EAL style certifications of systems. Yes, Sarbanes-Oxley requires it too, and yes, some companies (search for the word ‘epoxy’ in that link) disable the USB ports of their employees computers.
Copenhagen, Denmark - December 2005
I wrote some notes about how to fix this in what I consider a sane way. Sane here includes allowing a system administrator or home user to override this in a way that just works, e.g. pop up a dialog asking for auth to gain privileges to carry out the operation. Mocking around with configuration files in /etc does not qualify - do not pass start, do not collect $200 - put up a GUI dialog instead; it’s 2006 for crying out loud 
Anyho, so I did this policy library and started to integrate it with gnome-mount. Sure, this example is kinda lame and the UI is still totally wrong. But it illustrates the point well. The sysadmin didn’t allow the user to override file system permissions on an advanced file system and we give the user the ability to correct it - there are lots of more interesting use-cases than this. And we need do need lockdown, otherwise all the Michal Jaegermann and Alan Cox’s of the world won’t let us put it in a general purpose operating system. Which is fair enough. Oh, before someone cries the root password is evil; whether we ask for the super user password, users own password or something different for auth should just be up to the OS vendor. It’s a boring implementation detail. It’s also fine by me to have a gconf key to hide these dialogs; that might be sometime a sysadmin in an enterprise setting would do. I think Clark even suggested once to put a button “Send request to sysadmin to enable feature” too. Whatever
Paris, France - January 2006
Whilst implementing this I researched various graphical su helpers including consolehelper / usermode that we ship in Fedora. They all suffer from the same set of problems most notably that they allow to run X applications as root. So, I guess for HAL I’ll be rolling my own just like everyone else . Read on please.
No, seriously, I strongly believe the idea of even allowing X applications to run as root is a dead end from day one. With the su helper I plan for PolicyKit (which is a project I’ve spun off HAL containing said policy bits), your application will at most be elevated to an unprivileged “system user”. The trick here is that HAL allows this unprivileged user to invoke D-BUS methods normal unprivileged console users wouldn’t be allowed to invoke. To get to this “system user”, the desktop user will have to auth (root password, own password, whatever) and will thus be presented with a dialog even (optionally) offering the one-time-pain option by granting this privilege to the desktop and/or other users forever (or until the sysadmin changes it).
Boston, MA - December 2005
The reason I’m spinning it off HAL is that it makes sense for the rest of the desktop bits (not only GNOME) to adopt the same architectural pattern; for example gnome-system-monitor could use this to renice processes.. g-s-m will simply provide a service on the system bus that runs as root and exports a method called Renice(). A PolicyKit policy file provides a list of uid and gid for who is allowed for this. Now, g-s-m will try to invoke Renice() but might get the PermissionDeniedByPolicy exception back. If this is the case, simply bring up said dialog, enter password, optionally grant this privilege to one or more users and, bingo, you’re done.
I plan to provide a PolicyKit-gnome library for these dialogs, e.g. password prompting and policy editing. Mostly because this is what I need for the HAL (and Fedora I guess), but I think it makes sense for GNOME too to consider this architectural pattern.
Yea yea, long boring blog post about admin stuff and it’s not even about cool bling stuff!. I hope at least that the admins love me
