Friday, November 17, 2006

Fast User Switching

I’ve just put up some notes about Fast User Switching and how we plan to integrate this into Fedora for our next release.


Most of this work builds upon ConsoleKit by the ever-so-awesome Jon McCann of gnome-screensaver fame. It’s not very Fedora centric so hopefully other Linux distributions (and other free UNIX-like systems like OpenSolaris and FreeBSD) will pick it up too. I’m excited, in particular, about the fact that, with infrastructure like this, we’ll be able to enhance applications to behave intelligently when f-u-s is used, e.g. pause media playback, go to away mode for IM etc.



pjones, campd and J5 at Charlies
Don’t forget the beer tonight


Going to pick up Kay later in the PM, he’s flying in from Hamburg. We’ll most likely end up at Flat Top’s later tonight for Dave’s shindig!


A few days ago Artem merged the Solaris backend for HAL. Awesome. The FreeBSD backend is going to be merged real soon now as well, the patch is already on the list.

Thursday, November 16, 2006

Thursday, November 9, 2006

Trying to be Constructive

Daniel, actually I wasn’t referring to binary drivers per se in that particulary obnoxious post of mine; what I had in mind was primarily out-of-tree drivers / features including ones that explicitly disable rootkit prevention features for example. Using the word damaging to the free software community however was perhaps over the top, sorry it upset you and probably others, but I just don’t think including a bunch of not-so-heavily-audited code (e.g. a driver that is not in mainline) or code that disables security features is doing your users service. Most users of course don’t care, but developers like you and I should. In particular, OS vendors needs to care.


It seems you and I don’t disagree on Linux based distributions including proprietary drivers but I think that one thing you might not realize is how damaging it is when a popular distro starts doing this… years of work in dealing with certain vendors to open up code is undone in a jiffy. I don’t want to be all moody here, trying to be constructive (could use much stronger words but that would serve no purpose), but it’s flat out depressing when stuff like this happens.


With regards to you commenting on the Fedora community, most of your points, I think, are well understood by the community and some are being dealt with. For the record (and this should be clear to anyone involved in the areas I also participate in), I think of myself much more as an upstream guy rather than a Fedora guy as I think it’s silly we have all thesse differences between distributions - just do the work upstream (swim upstream dammit :-) ) instead of adding distro-specific non-sense unless it’s absolutely necessary (things like branding, defauls etc. all fall under this). I think you know this already, so please don’t tag me as a Fedora guy just because I’m ranting about other distributions on my personal blog space. I happen to use Fedora because it’s aligned with my personal views about free software, because it’s a first class distro with cutting edge features… and also, of course, because I’m paid to work on the software by my employer.



_MG_1630.CR2
introspection, bridges and people driving by


The larger problem, in my view, is really that we have some work left in building bridges between the various communities that participate in writing code for the GNU/Linux system. Heck, even inside a company like the one I work for it’s sometimes difficult to coordinate features between kernel, base os and desktop teams, sometimes even more difficult that dealing with other downstreams. However with collaboration zones like freedesktop.org we’re slowly getting there and things do look a bit better than they did just two years ago - next up, for example, is pm-utils so distros can start sharing quirks and infrastructure to improve the power mangement mess.


I hope this clarifies.


(Disclaimer: I am employed by Red Hat and am paid to work on (among other things) Fedora but my views are strictly my own.)


(Oh, and I also think it’s called “The New Pink” instead of “The New Black” but, uh, maybe saying that just reveals I’m eligible for membership in the GNOME old farts club.)

Software Freedom and Dealing with Resume Failures


  • Go read davej’s thoughts on Why Fedora isn’t Ubuntu. Required reading for people who believe in free software and thinks shipping insecure drivers is a bad idea. Choice quote: Maybe we can get a spaceman with lots of money to pay for the subsequent legal costs too.

  • Someone here at Red Hat was unhappy about a review of early RHEL5 code where Suspend to RAM didn’t work for the reviewer. Though I’m of the firm opinion that the root problem should just be fixed, reality is that it won’t get fixed anytime soon. So I ended up hacking up something so if suspend/hibernate fails… the user is presented with this on his next login:


    Problem resuming, buddy!
    Problem resuming, buddy!



  • This (somewhat useless) dialog is just the beginning; the long term upstream plan is to hook this up to Bug Buddy. Determining when to show this dialog is actually really difficult because the most common problem is that the system resumes just fine but the video isn’t turned on. And there is no chance of detecting such a failure programmatically, hence we need to be smart about it; find patches and more information here. I expect this to land in Rawhide pretty soon.

  • Am still in RHEL5 bug fixing mode; at least there’s light at the end of the tunnel so I can return to doing upstream work.

Saturday, November 4, 2006

Can Mr. Smith Get to Washington Anymore?

Saw Can Mr. Smith Get to Washington Anymore? at the Kendall Square Cinema last night (review here). Movie itself was good. What was pretty awesome was that after the movie there was a Q and A session featuring Jeff Smith himself where we could ask questions about both the movie, the grass root stuff and his current political engagement.


If you have the chance run, don’t walk, down to the cinema and see the movie.

Friday, October 20, 2006

Random Stuff and Random Flames


Looking at myself
Looking at myself or looking at you?



  • Just booked tickets for LCA 2007 in Sydney, Australia in January 2007. Am also taking some vacation to bum around .au the week following the conference. Am also planning to submit a proposal for the GNOME miniconf.

  • Sad to see yet another defector. Here’s a very insightful comment from davej about some of the damage done to the free software community.

  • Less-than-insightful rant about “crappy HAL” that frankly pisses me off.

  • Spent around 3-4 days optimizing HAL for CPU and memory consumption, here are the difference it makes on the 770, courtesy of Rob Taylor

  • Am almost done with a huge freakin patch for activation on the system message bus. Will need to write down how this relates to some of the init replacement projects out there; here are some thoughts about that for now, but it really deserves a full blog entry.

  • With the D-Bus bits (system bus activation) in place, I can move forward and do some PolicyKit stuff that requires the D-Bus bits in order to be useful.

  • Trying to spend lots of time on work-stuff since personal life is a bit busted at the moment.

Friday, October 6, 2006

Embedded


Embedded Summit at MIT's Media Lab

At the Embedded summit at MIT Media Lab

Monday, September 11, 2006

Drinks, Software and Gambling











How to make a David Zeuthen
Ingredients:
5 parts friendliness
1 part humour
5 parts energy
Method:
Add to a cocktail shaker and mix vigorously. Add a little fitness if desired!



Username:


Personality cocktail
From Go-Quiz.com



In other news I just released HAL 0.5.8 “The Skynet Funding Bill is passed.”. Get it while it’s hot!



Luxor Hotel in Vegas
Only in Vegas!


The girl and I went to Vegas over the Labour day weekend. I’ve uploaded some photos here. I was lucky at the roulette table too (put some $15 at my age, yeay!), got home with $700 more in the pocket.



Wednesday, July 26, 2006

Sweet Irony

I’ve just released HAL 0.5.7.1 “Unmaintained piece of crap” and all vendors should upgrade as Linux kernels later than 2.6.17 will break HAL 0.5.7 (e.g. HAL will break in hardware detection, not the kernel). It should be a smooth upgrade and credit goes to Kay Sievers for the patches.




Reflection
Introspection


Just a few hours after my last entry, Jonathan Corbet of LWN found me at OLS and said it wasn’t LWN badmouthing HAL, he was just reporting what was going on at the kernel summit. So, sorry if I made it sound like it was LWN’s fault, it wasn’t, I do believe in free press and LWN is just an awesome resource. Oh, I just find the whole “unmaintained piece of crap” thing slightly amusing (hence the release name for 0.5.7.1) - the community around HAL is alive and well even though I’m not presently around doing HAL stuff as much as I like.

Thursday, July 20, 2006

Linux Symposium

I appear to be in Ontario, Canada. More specifically I’m in Ottawa though hours last night was spent at a bar in Quebec.



In Logan's terminal 3
In Logan’s terminal 3 enroute to OLS


Yesterday, Kay and I gave a talk on Dynamic Device Handling on the Modern Desktop and I think it was well received. Yeay!


Oh, and I’ve even got to say that hal-device-manager (the small python GTK+ app for viewing the hal device objects and their properties) was an “unmaintained piece of crap” alluding in a funny way to the recent LWN article badmouthing HAL. Some people in the audience laughed. Lots of excellent questions too. Good times.


I’ve uploaded the slides from mine and Kay’s talk here. Enjoy.

Thursday, July 13, 2006

PulseAudio and GNOME

Talked briefly to Monty yesterday about PulseAudio and how it would fit into GNOME. Here are some notes, I may be way off, but I thought it would be good to blog them anyway.



Monty!
Monty making an elaborate point about mixing stuff



  • Multiple Soundcard Configuration: The gstreamer sink for PulseAudio should use the same gconf settings as for the gstreamer-hal-gconf sink as discussed here. Then we would be able to reuse the same dialog which would be nice. I have no idea whether this is feasible, desirable or possible in the context of PulseAudio.. But I thought I’d mentioned it anyway, it makes sense to me and… IIRC, a number of applications such as Totem and Ekiga is moving to selecting outputs (using gstreamer) based on whether they output “Sound Events”, “Music or Movies” or “Audio/Video conferencing”.

  • Power Savings: To be honest, I’m not sure whether PulseAudio runs as a system daemon or in the desktop session or whether it’s configurable (sorry, haven’t done my homework). But surely, to me, it needs to run in the desktop session. It should talk to gnome-power-manager, via D-BUS, and keep track of whether the user “prefers power savings over performance” (yes, this is a user preference which defaults to on when running on battery and off when on AC).
    So if “prefers power savings over performance” is enabled as a desktop session wide setting (or if it changes state - it’s a live variable so need to listen to D-BUS signals from g-p-m), PulseAudio should close the file descriptor to files in /dev/audio when there is silence so the kernel drivers can put the sound card(s) to sleep. Not only that, if the sound card is used only for output it should open with O_RDONLY so parts of the sound card can be powered down. Specifically for projects such as OLPC this is important and Jaya Kumar already done the kernel side of this.
    Sure, when the sound card is turned on again there is a slight pop, but users for which this is the end of the world… they can tweak the setting in g-p-m or perhaps use a specific PulseAudio setting to override. But by default, PulseAudio should ask g-p-m so we can suspend sound cards on battery when not used. It’s about saving energy.. think of the kids, Der GrĂ¼ne Punkt, EnergyStar and all that! :-)



In other news, Mitra got a Macbook and she seems thrilled about it so far. Also, I didn’t know that Mitra’s mom have been in outer space.

Thursday, July 6, 2006

GUADEC recap

Got back from GUADEC and Spain on Sunday. Nice conference; I liked the touch with seven days instead of three even though it was a bit exhausting in the end. I’ve also got sick around Saturday so spent that day in bed in my hotel room before traveling back Sunday. As a result of all this, I’m way behind on mail so to those who I owe a reply, hang in there, I’ll get back to you eventually.



Robert and Joey in what could be a movie poster


Robert and Joey as batshit insane movie stars?



I’ve now uploaded the slides from my talk (ODP, PDF).



Bummed out
Taking a break from the action at the Fluendo party


I enjoyed the 4th of July fireworks from my balcony in Somerville, MA overlooking Boston



Zeppelin?
Zeppelin just after dropping it’s payload on Boston, MA?


All my GUADEC pictures are available here.

Monday, June 26, 2006

At GUADEC

Made it to Spain on Friday, surprisingly Delta brought me there at 7:45am as scheduled. Spent Friday walking around Barcelona with Kay and his girlfriend. Nice but a bit exhausting given we were out until 8pm. Made it to Vilanova late Friday night and, hours later, was surrounded by nice people and cold beer. Good times. Fell asleep around 1-2am.


I can’t believe noone else at GUADEC blogged about this guy at the registration desk:



GUADEC registration desk


“Pick me up”



I haven’t blogged for quite some time, should get back in the game. Despite that lots of things have happened in work, HAL, PolicyKit and also RL that I will need to report at some time. Now to get some lunch and see some talks!

Sunday, April 2, 2006

System Configuration

So once again the topic of system configuration and Elektra (aka LinuxRegistry) has come up on fedora-devel-list and since I know most people even on the list don’t keep up because of the sheer volume, I’m going to use my blog to link to my response.



WCC2006-20060401-032
Denmark vs. Japan at WCC 2006 - EOS 20D and 70-200mm f/2.8 lens @ ISO 400


It shouldn’t be a surprise to people knowing me that I consider myself a UNIX hater. In fact, this whole thread on f-d-l made me realize that the with regards to system configuration you really only want two things: session-wide and site-wide configuration. Maybe it’s time to open a CafePress store and pimp shirts and stickers with the mottos a’la # rm -rf /etc. Seriously.


Received my MacBook Pro last week and I’m psyched. Now to get Fedora installed :-) .

Tuesday, March 7, 2006

System-wide Lockdown and Usability

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.



Boat on reflecting water
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 :-)



Eiffel Portal
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).



Looks like a wall of gold
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 :-)

Tuesday, February 28, 2006

Secretary plugged hairdryer into UPS

Yay! My LUKS integration bits landed in Rawhide and will be in Fedora Core 5. In other news, the latest gnome-power-manager in Rawhide works really nicely with non-portable batteries e.g. Uninterruptible Power Supplies that supports the USB HID protocol.




New and l33t icons


Richard been kicking ass on gnome-power-manager recently - note how he even fixed my somehow pedantic requests to even make this work when hotplugging the UPS.

Tuesday, February 21, 2006

There is no security on this earth, there is only opportunity

I’ve been hacking on and off with W. Michael Petullo on integrating LUKS into the GNOME desktop via HAL and patches are now upstream.. I think it rocks. I’ve prepared a small screencast:




Screencast of LUKS integration into GNOME


Hopefully we can get these bits into FC5; the patches themselves are pretty simple but you also need HAL and gnome-mount from CVS. I’ll do releases of the latter two later this week.


We still need some UI for setting up volumes; this should probably be integrated with gfloppy or maybe an entirely new UI for partitioning and formatting media. Fortunately, however, someone is already working on this but to do this securely we need to formalize privileges in HAL and I think there is consensus about how we want to do that.


In other news, danish are renamed in Iran. Some times, the world is so silly that it’s sad.

Monday, January 9, 2006

New year and Policy Daemons

New Year, Same Old


It’s a new year and I returned late last week from Europe - nice with relaxation but maybe a bit too much travelling… Anyway, pictures speak much more than a thousand words, or something, so nuff’ said. I’m not sure I like 2006 yet, maybe things will change.



From lunch of the day of christmas eve
Danish food


For new years I went to Hamburg, Germany to visit my good friend Kay Sievers - awesome to see Kay again. With Kay working for Novell and me working for Red Hat we talked a lot about the current state of our various distributions and how we can work closer together in the trenches. Specifically we discussed how to manage policy enforcing daemons and below are some of my thoughts on that.


On Enforcing Policy


Background


Starting with Fedora Core 1, Red Hat started shipping the system-wide bus (D-BUS) in Fedora Core, but it wasn’t until Fedora Core 3 with the advent of HAL and NetworkManager that the bus started to see extensive use.


Today, in what will become Fedora Core 5, unpriviliged applications running in a desktop session on the console can invoke methods for putting the system to sleep, configure display brightness on laptops, configure networking and mounting storage devices. With time, more and more methods will be available for configuring the hardware and/or system. All such method invocation happens in a secure way through the (unprivileged) system bus daemon that checks, validates and passes messages between the sender and receiver. Additional lock-down via e.g. SELinux security contexts are possible too but I’ve yet not seen anything use it.


Configuration


Back in the day, the traditional UNIX way for system-wide daemons prescribed using a textual configuration file somewhere in /etc - acpid and networking scripts comes to mind. With this, users had to resort to using a text editor and learn about the configuration file format; very educating and l33t for the geek hacker, but not ideal for ordinary users; not ideal for grandma. When available, UI tools simply rewrote the configuration file which most people agree is error prone and just plain wrong.


Allowing applications in the desktop session to enforce policy makes a lot of sense from a configuration point of view. Today, in the development tree of Fedora we now ship gnome-power-manager. Settings are read from gconf at /apps/gnome-power-manager. We have a nice, not horrible at least, user interface (Desktop -> Preferences -> Power Management) for configuring the policy. It is per-user, and since it uses gconf it’s possible to configure both default and mandatory settings (for lock-down), these days this can even nicely be achieved with e.g. Sabayon. In almost every way possible way it’s superior to textual configuration files. John has some good stuff about gconf here.


Also, gnome-power-manager sports a notification icon along with a menu for performing actions such as putting the system to sleep or hibernation. These days, when the kernel is in a good mood, power management just works. It’s like using my Mac.


However, there are two obvious downsides to running policy enforcing daemons in the desktop session, namely




  1. when no user is logged in, no copy of gnome-power-manager is ever running; hence no policy is maintained; hence your laptop won’t suspend after e.g. 15 minutes of inactivity when at the login screen.


  2. when multiple users are logged in (either via fast-user-switching or via multiple physical consoles) multiple copies of gnome-power-manager are running. This is bad as e.g. inactivity on one console might trigger e.g. a system suspend.


Exactly the same problems apply for the screen saver (gnome-screen-saver), networking (nm-applet), storage management (gnome-volume-manager) and probably other things too. Wonder why there is no screen saver on the login screen? Wonder why your wireless network isn’t configured before login? That’s why.



Opera house and the Canal
The Opera House in Copenhagen, Denmark


A framework


To solve problems 1) and 2) above we first need some infrastructure for tracking what sessions are at the consoles attached to the system. Remember that several users can be logged in at the same console through fast user switching (even multiple sessions from the same user on one console) so we need a notion of who and what is active at each console.


The proposal is a simple D-BUS service on the system bus; in quick and dirty pseudo code it would look like this



service org.freedesktop.DBus.ConsoleTracker {
methods:
array{tupple{string sessionId,int console, bool isActive}} GetSessions();
int GetNumberOfConsoles();
int GetUnixUidFromSessionID(string sessionId);
signals:
SessionBegin(string sessionId, int console);
SessionEnd(string sessionId, int console);
SessionActivityChanged(string sessionId, int console, bool isActive);
NumberOfConsolesChanged(int numConsoles);
}

The sessionId is simply a unique identifier maintained by the ConsoleTracker service - most likely this is the X11 display number though ConsoleTracker shouldn’t rely on a certain windowing system. The isActive boolean denotes where the session is currently visible on the console. Along the way the ConsoleTracker service may also provide methods such as GetSessionBusAddress(string sessionId), it might provide properties to tell what kind of session is running (GNOME, KDE, …) but that is beyond the scope of this write-up.


A service like this (I’m sure the choice of names and methods / signals can be much improved) simply tracks sessions and, as such users logging in and out. Ideally this service is shipped with the D-BUS tarball and ideally we’d make the system bus dependent on this service insofar that we can introduce policy directives such as “at_active_console” etc. in addition to the “at_console” directive we already have.


The ConsoleTracker service should also be possible to implement without pam_console which means that we can get rid of the optional pam_console dependency in D-BUS. This also means that e.g. HAL and NetworkManager can ship D-BUS configuration files with “at_console” without the Debian people having to patch things out and only users logged in at the console may invoke methods like e.g. Suspend() to put the system to sleep. Of course, the Debian people may still change the policy because they think group membership is more correct. It’s their OS distribution after all.



Sketchy Rupert
Rupert spotted in Germany


Now, with the ability to track logged in users and sessions, it becomes almost trivial to write the next system-wide service, let’s call it org.freedesktop.PolicyManager. This is a daemon that reads configuration files in /etc/PolicyManager.d/ (only programs will dump files here, not people)

/etc/PolicyManager.d/power-management.conf
storage-management.conf
...


where e.g. power-management.conf contains

[policy-service]
exec=/usr/bin/my-power-manager-when-no-one-is-logged-in
id=PowerManagement
per_console=false


which simply states that the PolicyManager daemon should run the program /usr/bin/my-power-manager-when-no-one-is-logged-in when no user is logged in (the console number is passed in the environment). This configuration file also provides a unique identifier for the kind of policy service it is, in this case power management. Part of the “specification” for the PolicyManager daemon contains a list of well-defined policy services, e.g. PowerManagement, StorageManagement, ScreenSaver, NetworkManagement and so forth.



Conny the killer pony!
My sister has a Pony called Conny


The per_console field requires further discussion, but let us first take a look at the D-BUS interface offered by the PolicyManager daemon:



service org.freedesktop.PolicyManager {
methods:
bool ClaimPolicyService(string id);
bool ReleasePolicyService(string id);
signal:
PolicyServiceClaimed(string id, string sessionId, int console);
PolicyServiceReleased(string id, string sessionId, int console);
}


The thinking here is that when I login to the GNOME desktop, then gnome-power-manager is started and it invokes ClaimPolicyService("PowerManagement") on the PolicyManager system service. Since D-BUS now sports the ConsoleTracker service, the PolicyManager can determine what console, if any, the method call from the gnome-power-manager instance stems from. Specifically, if the method invocation stems from a process not at the console it is denied.


The PolicyManager service now kills the existing process responsible for power management, e.g. /usr/bin/my-power-manager-when-no-one-is-logged-in, and returns TRUE which means that our copy of gnome-power-manager is set to go. This daemon starts enforcing policy, e.g. suspends my laptop after inactivity and so forth.


Whenever my copy of gnome-power-manager terminates (normally when logging out), then the PolicyManager is notified through a signal on the system message bus (already part of the system bus) and starts up /usr/bin/my-power-manager-when-no-one-is-logged-in to enforce policy. Also, at any point my gnome-power-manager copy may invoke ReleasePolicyService("PowerManagement") if the user e.g. manually disables it (though it is unlikely why g-p-m would provide such functionality).


Suppose that user A is logged in at console 0, it’s session "s100", and has a copy of gnome-power-manager runnning. Now suppose that user B logs in via fast user switching at console 0, session "s101". The following happens.


First, the ConsoleTracker service emits a signal telling that session "s100" is no longer active, SessionActivityChanged("s100", 0, FALSE), and the gnome-power-manager copy in session "s100" receives this signal and stops enforcing policy (it doesn’t invoke ReleasePolicyService() though). Now another copy of gnome-power-manager for user B starts up in session "s101". It also invokes ClaimPolicyService("PowerManagement") on PolicyManager and it recieves TRUE and this copy starts enforcing policy.


When switching back to session "s100", the g-p-m copy in session "s101" stops enforcing policy, due to SessionActivityChanged("s101", 0, FALSE), and the g-p-m copy for session "s100" starts enforcing policy in response to the SessionActivityChanged("s100", 0, TRUE) signal.



Dark skies and white snow
Frightening Sky


The per_console field, which is FALSE in the power management example, defines whether the policy enforcing daemon is per console or per system.


For example, consider a system with two consoles, 0 and 1. Since per_console is FALSE for power management only one copy of /usr/bin/my-power-manager-when-no-one-is-logged-in is launched. When there are two user sessions, one on each console, only one of them get to enforce policy, e.g. ClaimPolicyService("PowerManagement") will fail for one of the two copies of gnome-power-manager. The loser will probably revert to only showing battery information, not enforcing policy, and it is up to the two copies to negotiate when to suspend the system. This may be done in a number of ways.


So when is per_console=TRUE useful? It’s useful for policy enforcing pieces like the screen saver or the storage manager. In general, it’s useful when you want a copy running for each console. For example, when PolicyManager starts up on a system with two consoles, it will launch two copies of the /usr/bin/my-screen-saver-when-no-one-is-logged-in (how it gets access to the X display is another matter though). Specifically, for storage management, e.g. gnome-volume-manager, one also wants to ensure that policy is only enforced for drives local to the console, e.g. only mount USB storage for the USB ports local to the console. How this is determined is beyond the scope of this write-up for ConsoleTracker and PolicyManager but it’s not difficult to imagine that this information could come from HAL.


Reusing desktop policy daemons for system use


One problem remains to be solved. How do you configure the policy for the policy daemon when no user is logged in? Also, why would you want to maintain two code bases; one for desktop case and one for the case when no use is logged in? The answer here is simply to reuse the desktop policy daemon. For instance, for power management we get



[policy-service]
exec=/usr/bin/gnome-power-manager --no-one-is-logged-in
id=PowerManagement
per_console=false


and gnome-power-manager simply don’t provide any UI (or maybe it paints the UI on top of the login screen, e.g. gdm). Since this copy of gnome-power-manager is invoked by the PolicyManager daemon it runs as nobody or some other unprivileged system user. It still reads it’s setting from gconf but since this is not a real user it will get the default settings.


With this approach the UI for gnome-power-manager may include a button “Set as system default” that simply copies the settings from the logged in users gconf schema to the system default ones in /etc/gconf/gconf.xml.defaults. This of course requires administrative privileges and we may even hide this button if we can detect whether the user is an admin or not. Notably this will also work for other policy enforcing daemons, e.g. NetworkManager’s nm-applet, the GNOME screen saver and so forth.



Confetti is everywhere
Confetti is Everywhere


Not tied to one desktop


I’ve used GNOME as an example above, mostly because I’m a GNOME user and developer myself, but nothing prevents KDE or XFCE to do the same. Indeed, if there is agreement on all desktops using the ConsoleTracker and PolicyManager things will “just work”. Of course, someone will have to write this stuff :-) , I’m just rambling about one possible framework.