Monday, November 26, 2007

Politics. Mudslinging. Chocolate.

Whether Murray is right or not, I think his recent rant is rather tasteless and I agree some kind of retraction/apology is needed.

FWIW, Murray’s post certainly don’t reflect what I’ve experienced when I started participating in the GNOME project 2003-2004ish. That said, I acknowledge it may reflect what others have experienced. I don’t know. Also, I tend to stay out of politics… at least politics on that level. That said, I do appreciate others doing all this work; for a project of GNOME’s size we do need people in the foundation and some board, we need people spreading the word around GNOME, we do need to participate in standard organizations etc.

Either way, this kind of mudslinging is very unproductive for the project and everyone involved should know better. An old friend of mine once said “Can’t we just focus on the chocolate?”. This was in reaction to stupid in-company fighting and also a pun on a tv commercial from some chocolate company. The commercial involved three chocolate makers. They were making chocolate. Or rather, two of them were ranting about all sorts of non-sense and as a result they didn’t make much chocolate. At some point the third guy just had enough and he started whining. Much like me in this post.

Guys, can we please focus on the chocolate instead of all this non-sense?


Sunday, November 18, 2007

On Xguest, Access Control and Desktop

Dan, I think the ideas behind Xguest are nice. But your ideas about using SELinux to implement access control for users leaves much to be desired. If you think that a brutal approach of denying individual users to even access services like HAL, NetworkManager and Bluez is good, then please think again. Please realize that if you do this, the desktop experience will suddenly change. Things like networking and bluetooth applets will cease to work. The file manager will fall back to relying on /etc/mtab and /etc/fstab. I’m not sure PulseAudio will start.

The problem is that your approach is not fine grained; it’s all or nothing. And this is not really useful. For example, for NetworkManager what you want is to lock down the machine so the user can only connect to trusted networks. With e.g. trusted networks being defined as something that is defined in a file in /etc that only uid 0 can change.

I’m not sure if it’s a surprise to you, but over the past year or so I’ve been working on and off on an application-level access control mechanism (similar to various RBAC implementations but with a few innovations on top) called PolicyKit that does all this. It’s specifically designed and optimized for desktop applications but can also be useful for legacy UNIX command line apps. It puts the administrator and users back in control since it provides a way for them to gain authorizations by authenticating and also supports systems like Ubuntu that has no root password. It provides a nice user interface for human beings to manage authorizations. There’s GTK+ widgets to make it really simple to integrate into existing applications (and KDE support is underway). The list of applications that are PolicyKit enabled is growing rapidly. It’s in all the major distributions. It encourages least privilege, e.g splitting a program into privileged and non-privileged bits.

It’s not that I hate SELinux because I don’t. I think SELinux is already very useful, just look at how useful SELinux is in confining network-facing and privileged services. I also have SELinux support in PolicyKit already and I plan (with your help) to make gnome-user-share run in a dedicated SELinux context so it is authorized to punch holes in the firewall without any configuration whatsoever (today it’s totally broken since g-u-s picks a random high port number to listen on). But, Dan, frankly, I think your use of SELinux to lock down access on the desktop is misguided. It’s a bit like if all you have is a hammer, then everything looks like a nail. I feel that it’s a bit sad that that two developers, working for the same company, in the same office are trying to solve the same problems. We really ought to do better.

(Disclaimer: this post does not necessarily represent the views of my employer, Red Hat, Inc.)

Update: A few people pointed out that I sounded too confrontational in this post and maybe they’re right. As I tried (and probably failed at) to explain it’s not either/or. Surely, there’s a ton of value in using SELinux to lock down privileged mechanisms like HAL, NM, Bluez and so on. Having PolicyKit and SELinux work well together is in everyone’s best interest.

Monday, November 12, 2007


Andy Oram wrote a nice piece on PolicyKit detailing what it is and some of the plans for the future. I also did a short walk-through recently on one of our staff meetings here at Red Hat, there are some pseudo slides here. On the topic of coverage I’ve recently add unit tests to all the library sources and gcov tells me we’re at 59%. Not too shabby.

Thursday, September 20, 2007

Policy, Mechanism and Time zones

In my last post I looked at D-Bus system bus activation and provided a step-by-step guide on how to use this. In this installment we’re going to look at a specific application of system bus activation; namely how it can be used from a desktop application to do a privileged operation: setting the timezone. This example will also feature usage of PolicyKit for lock down.

When dealing with programs that needs to do privileged operations, the first thing that one needs to do is to separate the mechanism (the piece of code actually doing the privileged bits) into a separate process from the rest of the program. The main program will then simply launch a small privileged helper whenever something privileged needs to happen. This is a good idea because it’s a lot easier to review a tiny privileged helper with minimal dependencies rather than a huge program that pulls in things like GTK+, Python, image loaders and what not. Typically, the privileged helper is written in a way such that it trusts no-one; it verifies all the incoming parameters and also checks whether the program that calls it should be allowed to do so. The latter part is where PolicyKit comes in - PolicyKit is an application-level toolkit that allows a mechanism to ask “is $USER allowed to do $ACTION?”. As such, PolicyKit comes with a set of data structures to help model these constructs.

Anyway, enough boring theory; the user experience we want is that the user can click on his predefined list of time zones to set it; something like this

modified intlclock

If the user is not privileged to do this action, we may show a dialog like this

stock PolicyKit-gnome dialog

that may (or may not) feature buttons to make the system remember that setting the time zone is OK. Such that the system won’t ask for authentication in the future. In other words, this is a one-time-pain dialog.

Let’s go through the code and see how all this works. First, we need to write a mechanism. This will need to run as uid 0 (e.g. root) and we choose D-Bus as the interface for using the mechanism. We choose a unique name for the service, org.gnome.ClockApplet.Mechanism and since we’d like to write it in C using dbus-glib, we need to write some XML to define the objects and interfaces that this service will expose. This is defined in this file. As evident, this service exposes a single object, /, that exposes a single interface org.gnome.ClockApplet.Mechanism that currently exposes a single method SetTimezone(string zonefile) where the argument to that function is a path to what time zone we want to use. The mechanism itself consists of two C files, available here and here and a single C header file, available here.

Then, exactly as in the last post we need a D-Bus configuration file and a D-Bus service file. There’s also a cheesy Makefile to tie it all together.

Now, with this mechanism in place, we can poke it via D-Bus

$ dbus-send --system --print-reply --dest=org.gnome.ClockApplet.Mechanism / org.gnome.ClockApplet.Mechanism.SetTimezone string:/usr/share/zoneinfo/Europe/Copenhagen
method return sender=:1.346 -> dest=:1.345 reply_serial=2

The usage of PolicyKit deserves some explanation. First of all, as stated in the docs, we need to declare one or more actions for our mechanism. As we only export a single action right now (setting the time zone), we declare only that one action via the PolicyKit .policy file here. When we extend the mechanism to e.g. provide functionality to set the time as well (via e.g. a SetTime(int64 secs_since_epoch) method) we can declare an action org.gnome.clockapplet.mechanism.settime in addition to our org.gnome.clockapplet.mechanism.settimezone one.

Now, whenever someone calls into the mechanism, we simply use libpolkit to query whether the caller is allowed to do the specific action:

sender = dbus_g_method_get_sender (context);
pk_caller = polkit_caller_new_from_dbus_name (system_bus_connection, sender, &dbus_error);
pk_action = polkit_action_new ();
polkit_action_set_action_id (pk_action, "org.gnome.clockapplet.mechanism.settimezone");
pk_result = polkit_context_can_caller_do_action (pk_context, pk_action, pk_caller);
polkit_caller_unref (pk_caller);
polkit_action_unref (pk_action);
if (pk_result != POLKIT_RESULT_YES) { /* bail out */ }

The system administrator can control, using the /etc/PolicyKit/PolicyKit.conf configuration file, exactly what users are allowed to do this and whether they are allowed to keep the privilege to do the action on a forever- or per-session basis. This shouldn’t be necessary since it’s possible to specify the default result for a given action. Distributors can tweak the .policy as they see fit; for example consumer-oriented distributions might want to patch this to make the defaults always be “yes” (to avoid the auth dialog entirely) and workstation-oriented distributions might want the defaults to be “auth_admin” (to require the system administrator password and not give a chance to remember the privilege). Finally, sites can override this using the system-wide configuration file, e.g. if I’m a huge site I can distribute a PolicyKit.conf file that allows certain users to always do an action, certain other users never to do an action, and finally a third set of users for whom I want them to enter their own (or the root) password. Again, see the /etc/PolicyKit/PolicyKit.conf configuration file for details.

The screenshots above show integration with the intlclock applet; that’s thanks to Matthias Clasen. I simply handed Matthias the mechanism code including a simple GTK demo application available here. This application simply attempts to call into the mechanism and if the mechanism throws the org.gnome.ClockApplet.Mechanism.NotPrivileged exception it uses PolicyKit-gnome (via the session bus) to prompt the user for authentication if applicable.

The PolicyKit stuff is mostly done; at least the plumbing is there. What I like to see is some more GNOME-ish porcelain to make this stuff even easier to use. First, it’s simply way too complicated to write dbus-glib D-Bus servers. There’s just way too much code; compare to the Python server in the last post. Second, I’d like to provide a small library with a subclassed GtkButton, e.g. PolicyKitGtkButton such that all the magic happens there and it shows e.g. a lock only if authentication will be needed. I’m also planning to do a song and dance at the Boston Summit about this. The list of users of PolicyKit right now includes only HAL. However, PackageKit, dconf and virt-manager are all in the process of picking it up. I’m also hoping NetworkManager and things like gnome-system-monitor will pick it up (for the process killing bits instead of falling back to running the entire UI as uid 0 just for this). With time, and not too much time, I’m hoping for PolicyKit to be a blessed dependency in GNOME and banish the idea of su/sudo wrappers to enable running X11 applications as uid 0.

Wednesday, August 1, 2007

System Bus Activation hits Fedora Rawhide

.. well, almost. Anyway, you can get packages here or wait until Rawhide opens again (it’s currently frozen for F8t1). Credit goes to Richard for finishing this work and getting it past Havoc. This is a really huge thing; it opens up a lot of possibilities for better desktop/OS integration.

Lots of pretty colors
Lots of pretty colors

To actually test the packages I wrote a simple test program and thought it might be useful to share it. First, you need a program that claims a name on the system bus. I just copied the one from the dbus-python repository and modified it slightly. You can see it here.

Second, as with any service on the system message bus (as opposed to the session bus which has different security characteristics) you need a file in /etc/dbus-1/system.d. Mine is named dk.fubar.Test.conf (but note that any unique file name ending in .conf will do) and is pretty much run-of-the-mill standard stuff and shouldn’t be a surprise if you’re familiar with services on the system bus. It looks like this.

Finally, for system bus activation to work you simply need to put a service file in /usr/share/dbus-1/system-services. Mine is named dk.fubar.Test.service (again, any unique name ending in .service will do) and looks like this:

[D-BUS Service]

and that’s it! Provided you installed everything correctly (there’s a cheesy Makefile to do this) things should Just Work(tm) and the following command should print

$ dbus-send --system --print-reply --dest=dk.fubar.Test /SomeObject dk.fubar.Test.SampleInterface.HelloWorld string:foo
method return sender=:1.517 -> dest=:1.516 reply_serial=2
array [
string "Hello"
string " from"
string "with unique name"
string ":1.517"

If your service is capable of operating correctly when running as an unprivileged system user (e.g. ftp or whatever) instead of root (think least privilege), simply change the user mentioned in both the .service and .conf files.

Thursday, July 19, 2007

No more polling

I just committed code to hal to take advantage of asynchronous change notification events originating from SATA AN capable drives. This means we can avoid polling the drive and this should result in fewer wakeups in libata. This also opens the opportunity for the drive itself to go into a deeper sleep state when it’s not used. So all in all this should improve laptop battery life. I haven’t tried this on a laptop just yet, but when I find a suitable one I’m sure PowerTOP will tell me.

Mural at the back of 1369
I took this while testing this GPS receiver. Click to see where to get good coffee.

Credit goes to Kristen Carlson Accardi from Intel. She did the kernel bits, sent me a SATA AN capable drive and pointed me in the right direction. To try this out, you will need a recent kernel and also some patches not yet in Linus’ tree. See RH #204969 for details. I’m hoping this will make it into Fedora 8; the hal bits will for sure; for the kernel bits I suppose asking davej is in order.

Wednesday, June 20, 2007

PolicyKit release

Late last night I finally made a PolicyKit release. It’s almost ready for prime time; wait a month for 0.4 to get out and I should be able to maintain a stable API.

PolicyKit in action

With Richard’s great work on D-Bus system bus activation it looks like we’re soon going to have nice upstream frameworks for enabling the desktop to do privileged operations in a hopefully sane way. Instead of having each and every distribution on the planet write their own configuration tools. I, for one, really wants to see some effort of merging such things into upstream GNOME and KDE as far as possible.

Tuesday, June 5, 2007


Normally I’m not opposed to what our new web overlords are serving us; you know; social networks and the ability to see what past and present, uh, peers are up to… but sometimes it’s just TMI - Maybe I just need to use the Interwebs less :-)

Monday, May 7, 2007

i’m in ur RAID, striping ur disks all the way to CA

Recently I acquired a pair of 500GB USB2 hard disks that I use in a RAID-1 configuration (on two different host controllers!); you know, to store my photos and other important, uh, stuff. I had some spare time this weekend to look at fd.o #6426 so I wrote a small patch to teach HAL about Linux software RAID.

gnome-device-manager showing Software RAID drive
RAID rebuilding

I also whipped up patch to gnome-device-manager such as to show the new properties introduced including whether an array is running in degraded mode or is being rebuilt. It’s pretty spiffy.

All that this code is doing right now is basically just listening to kernel events (via udev and priority data on /proc/mdstat) and then representing the RAID arrays as HAL drives and volumes. It’s spiffy because the RAID drive inherits things like storage.hotpluggable from the physical components (e.g. the two USB hard disks) so in my case the RAID array simply appears in Nautilus and is totally mountable just like a regular external drive. Works out of the box. Desktop integration++. However, we can do a bit better so for GNOME 2.20 I’ll be writing some patches to gnome-vfs and gvfs. You know, to use the new HAL properties to choose some helpful icons and icon captions.

Going forward, there needs to be some way of assembling and disassembling RAID arrays; hot-adding components to degraded arrays and so on and so on. Probably neither Nautilus nor gnome-device-manager is the right approach here. And there will probably be some sort of auto-assembly happening at the system-wide level anyway, need to sort that out with Kay (the udev maintainer) and also talk to various distro maintainers too. It’s also probably also time to revive my never properly announced GNOME Disk Utility project. Actually, that’s one reason that I split the Device Manager into a shell and library component; right now the shell is around 1200 lines (compared to 4000+ for the library) and there’s no reason that the Disk Utility shell would be a lot bigger. Plus it’s always awesome to put pretty UI on top of useful infrastructure.

Tomorrow I’m leaving for The Golden State to go the Red Hat summit, then hang out with Kay Sievers and finish off the west-coast invasion with FreedomHEC. The next two weeks are going to be busy.

Saturday, April 28, 2007

Battery Recall^WExchange

Just found, via the interwebs, that the battery in my 15″ Macbook Pro was recalled^Weligible for exchange almost a year ago although not for safety risks, merely because “… batteries supplied to Apple do not meet our high standards for battery performance.” [sic]. So that’s something. Anyway, since this is useful information, I wanted to add information to hal-info such that other Macbook Pro users would benefit as well. By getting spammed with a popup like this

Useful feature in g-p-m

But as it turns out this data is not easily available

$ cat /proc/acpi/battery/BAT0/info
present: yes
design capacity: 55000 mWh
last full capacity: 47150 mWh
battery technology: rechargeable
design voltage: 10800 mV
design capacity warning: 250 mWh
design capacity low: 100 mWh
capacity granularity 1: 10 mWh
capacity granularity 2: 10 mWh
model number: ASMB012
serial number:
battery type: LION012
OEM info: SMPN012

meaning it’s hard to match on anything sensible from the fdi file. Maybe this is because it’s a Smart Battery? FWIW, I can see that the sbs driver is loaded. Lazyweb, please help :-) - as comments on my blog are busted, please provide answers personally to me or, preferably, the hal list (requires subscription).

Btw, I couldn’t find this information by poking around in Mac OS X either… but it must be there; I mean, normal non-smart batteries record make, model and serial numbers just fine via ACPI. That’s what we use to tag other recalled battery units. So I’m sure it’s possible to get at. And if Apple wanted, they could easily have similar mechanisms for displaying notifications similar to the ones we have in GNOME. But I can understand it would hurt their bottom line. I guess.. this is one interesting aspect of getting your OS from the same vendor as where you get your hardware.

Anyway, I filled out the form and a new battery is on it’s way. I guess, uh, thanks Apple. Just wish you had notified me earlier and I wouldn’t have to find out this way ;-) .

Update: I suppose this isn’t technically a Product Recall; Apple specifically uses the word Exchange instead. I guess, from a legal point of view at least, there’s a difference. To me, as a consumer, it’s doesn’t make huge difference however… hmm.. maybe we need to add a new property info.is_eligible_for_exchange to the HAL spec to avoid using the word “recall” at all in such situations. I mean, to, uh, cover our collective asses from angry hardware vendors.

Friday, April 27, 2007

Native languages and poisonous people

I think, over the past 3.5 years I’ve been working on free software, I have sent more than 5,000 mails, all in English, to various mailing lists, most of them with more than a few hundred subscribers. It’s always a bit weird (even after living in Massachusetts for more than 2.5 years) to use your second language and I believe it will stay that way the rest of my life. Which is fine and all.

Sketchy Dane

In general, I’ve found that native English speakers are very nice to non-native English speakers. In stark contrast, for example, are natives of my own country Denmark; whenever a foreigner attempts to speak Danish everything becomes a bit weird. One common thing is that the native Danes try to switch to conversation to English because it makes them less uncomfortable. I guess there are many reasons for this difference of behavior; first, Danish is a small, insignificant (and dying) language, most people speak English anyway and not a lot of native English speakers have a second language at all. But it’s also a cultural thing. In particular, I find that it’s very easy to live among the Americans; they’re friendly (actually, I jokingly tend to say “it’s like living with the smurfs”; many, not all though, people here are just more optimistic about the future than in Denmark and the EU.). The fact that English is a second language have never been an issue for me at all.

Sketchy German

Until today. I guess there’s a first time for everything, the topic of my native language came up on the Fedora live cd mailing list just recently. Response here. Time to watch How Open Source Projects Survive Poisonous People (And You Can Too) again I suppose.

The whole thing just makes me a little sad inside.

Monday, April 2, 2007

hal 0.5.9

I just released hal 0.5.9. Lots of changes including dramatically reduced resource usage, Solaris and FreeBSD support, ACL management, ConsoleKit support and many other things. Get it while it’s, uhm, hot. Hopefully the next release won’t take seven months…

Stupid meme

Monday, March 12, 2007


Just received this in the mail today from Europcar Australia:

As the registered owner of the vehicle stated below we have received a Speeding Infringement Notice and, upon searching our records, we can confirm that the infringement was incurred during your rental period.

Guess I should have looked out for speed cameras.

Random photo plug: Darling Harbour in January

I’m slowly losing my patience with the gods regarding distribution of luck and fortune.

Saturday, February 24, 2007

Who Killed The Electric Car?

Yay, just found out that Who Killed The Electric Car? is available on-demand on Comcast. It’s pretty awesome so far. Update: favorite quote “they’ll make me drive a small car, make me be cold in my own home… in other words, make me live like a European.”. My gods, that’s awesome :-) .

I miss the summer (photo from Sydney, January 2007)

Weather here in MA continues to suck although my relatives in Denmark says it’s much worse there.

Saturday, January 13, 2007


Barely back in Boston (UTC -0500) after the xmas break in Denmark (UTC +0100), I’m now in Sydney (UTC +1100) for 2007. I don’t feel jetlagged though.

Coogee, NSW, Australia (not my bottles)

Managed to sleep a lot on my 24-hour journey; I was fortunate enough to be traveling with blizzard. We even got picked up at the airport; I suppose Chris’ description of us to the organizers was somewhat accurate :-)

Just look for crazy man and fisheye boy:

(Together, we fight crime!)

Now to check out of my hotel and find the campus of UNSW. Times are good.