I always wondered how others recognise non-Debian packages in the aptitude package tree. I also missed the additional priority level in the hierachy well-known from good old dselect. For the last one, I quickly found out that you can set the priority as subsection — it’s straight forward after you’ve read the documentation: Just add ,priority at the end of the default grouping method for package views under “Options → UI Options” in the aptitude menu. Getting the origin as given in the Release file of the repository a package originates from is a little bit more difficult. You need to use the pattern() group function with the appropriate search pattern: pattern(~O) Since already the default default grouping method for package views doesn’t fit into the dialog, I nowadays just edit /etc/apt/apt.conf directly for changes on aptitude’s default grouping method for package views. It now looks like this on several of my machines:

Aptitude::UI  
  Default-Grouping "filter(missing),status,section(subdir,passthrough),pattern(~O),section(topdir),priority";
 ;

In aptitude this looks like this:

[...]
  --- text - Text processing utilities
  --\ utils - Various system utilities
    --- Debian
    --- Mowgli
    --- volatile.debian.org
  --\ web - Web browsers, servers, proxies, and other tools
    --- Debian
    --- Opera Software ASA
  --\ x11 - The X window system and related software
    --\ Debian
      --- contrib - Programs which depend on software not in Debian
      --\ main - The main Debian archive
        --- Priority optional
        --- Priority extra
      --- non-free - Programs which are not free software
    --- Mowgli
[...]

Unfortunately this doesn’t work with all non-Debian repositories since a few repository maintainer, e.g. those from Emdebian, arrogate to just keep “Debian” as their packages’ origin. This could be solved, if there’s a possibility to group by e.g. repository URL (host and/or path). Another problem I haven’t solved yet is that grouping by origin does neither work with locally created nor virtual packages nor tasks — probably since all of them lack an origin. Those branches are just empty or don’t even show up anymore with this configuration. I probably have to dig a little bit more in the aptitude documentation to resolve this.

Now playing: E-Rotic — Max don’t have sex with your ex

Since yesterday, my Blosxom plugins are versioned in the Blosxom Project CVS repository together with those of most other Blosxom developers. Cause for this is, that — besides first steps towards Blosxom v4 (we better forget about v3… ;-) and intergrating existing patches (e.g. the Debian config file patch) to Blosxom v2 — the Blosxom developers want to release a Collection of common Blosxom Plugins as a Plugin distribution so that no one needs to gather the often needed plugins from various sites on the net but get them from first hand and also in some kind of a supported way. A first release candidate is on it’s way. And for those who thought good ol’ blosxom is dead: There never was so much traffic on the blosxom developer’s list like in the past two months — over 160 mails each!

Now playing: Eiffel 65 — Blue

In a comment on my previous post about SE Linux and worms/trojans [1] a user enquired about which methods of gaining local root are prevented by SE Linux. A local exploit is one that can not be run remotely. An attack via TCP or UDP is generally considered a remote exploit - even though in some cases you might configure a daemon to only bind to localhost (in which case the TCP or UDP attack would only work locally). When compromising a machine it’s not uncommon for a local exploit to be used after a remote exploit or social engineering has been used to gain non-root privileges. The two most common types of local root exploit seem to be those which attack the kernel and those which attack a SETUID process. For a non-SE Linux system it usually doesn’t matter much how the local exploit is run. But a SE Linux system in a default configuration will be running the Targeted policy that has almost no restrictions on a user shell session. So an attacker who wants to escalate their privileges from local user to local root on a typical SE Linux system has a significant benefit in starting from a user account instead of starting from a web server or other system process. In the SE Linux model access is granted to a domain, and the domain which is used for a process is determined by the policy based on the domain of the parent process and the labelling of the executable. Some domains are not permitted to transition to any other domains, such as the domain dhcpd_t (used for a DHCP server). Other domains are only permitted to transition to a small set of domains, for example the domain httpd_t (used for a web server) can only transition to a small number of domains none of which has any significant privileges. On a machine running without SE Linux a compromise of a DHCP server is game-over as the server runs as root. A compromise of a daemon such as Apache on a machine without SE Linux gives unrestricted access to run applications on the systems - if a SETUID-root program has a security flaw then you lose. The same bug in a SETUID program on a machine running SE Linux is not fatal because SE Linux will prevent the program from doing anything that it’s parent could not do - even if an attacker made Apache run a buggy SETUID program the broken program in question could do nothing other than what Apache is normally permitted to do. A security flaw in a SETUID-root program on a SE Linux system can still be exploited by a local user (someone who has logged in) when running the Targeted policy. When running the Strict or MLS policies many such vulnerabilities will not be exploitable by local users (for example exploiting PING would only permit network access). As a rule of thumb you should consider that a kernel security flaw will make it possible to bypass all other security features. However there are some situations where SE Linux can prevent local exploits. One example is a bug discovered in July 2006 which allowed the creation of SETUID files under /proc [2], the targeted policy of SE Linux prevented this from working. Another example is CVE-2003-0127 [3] (a kernel security flaw that was exploited by triggering a module load and then exploiting a race condition in the kernel module load process), the commonly used exploit for this did not work on a SE Linux system because the user process was not permitted the socket access used to trigger the module load (it is believed that an attacker could have written a version of the exploit to work on a SE Linux system - but AFAIK no-one ever did so).

• [1] http://etbe.coker.com.au/2007/10/08/selinux-storm/


• [2] http://lwn.net/Articles/191954/


• [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0127

Share This

In general, if you’re doing a repetitive task by hitting lots of keys, you’re doing it wrong. Not only are you wasting time, you’re wearing out your keyboard and damaging your wrists and fingers. Here are the ten most common anti-patterns (actually amelioration patterns) that I commonly see in other people’s line editing:

1. Repeating a command by retyping it
   Press Ctrl-p and Enter, or “!!“. Zsh users get “r” as well. You can even get the command n times before, use “!-1“. Using the arrow keys is obviously flawed - find out how to unmap them in your shell.
2. Manually changing back to your previous directory
   Give “cd -” a whirl.
3. Typing a long command (or sequence of commands) excessively often
   Obviously wrong, but I see it so often it’s worth mentioning. Try using an alias and put it in your shell’s startup file. If the command is parameterised, you could construct a simple function. If you are writing software, look into the build systems available for your language - the basics of GNU Make can be mastered within 20 minutes or so, and have many other benefits too.
4. Opening another shell when the current process blocks
   (e.g. You realise the command you started is going to take a lot longer than you thought) Pause the current process with Ctrl+z and then put the job in the background with bg. fg will bring it to the foreground again. Fewer shells mean you stay focused on what you were trying to achieve.
5. Searching history by grep’ing ~/.bash_history, or Up Up Up … etc.
   Use CTRL+r (or “/” in vi-mode) for search-as-you type. You can immediately run the command by pressing Enter.
6. Adding a prefix to a command with Up Home $command Space
   (e.g. You ran a command that really needed sudo). Try: $prefix !!
7. Changing a command with Home Right Right Right Right … BkSpace BkSpace … etc.
   (e.g you accidentally ran chown instead of chmod) Try: $new_command !*
8. Retyping significant parts of the previous line

   $ command arg1 /long/path/to/file
   $ command2 arg2 /long/path/to/file
   $ command3 arg1 arg3 /long/path/to/file

   Try using !$ to get the right-most argument on the previous line (you can also use !:2 to get the second argument, etc.):

   $ command arg1 /long/path/to/file
   $ command2 arg2 !$
   $ command3 arg1 arg3 !$

9. Using Home/End to move to the beginning/end of the line
   This is how you completely ruin your wrists. Use Ctrl+a and Ctrl+e.
10. Hitting tens of keys to make a substitition
    (e.g. you made a trivial mistake in the middle of your previous command). Use ^foo^bar. If you forget the other nine, try this one - stop punishing yourself for making mistakes!

Now that through black magic, voodoo, and a working network driver I have Avahi working on my NAS and UPnP working on my SoundBridge, I can get back to the task of learning a bit about GUPnP, a GObject-based library for UPnP. My first hack is a simple tool that pops up notification bubbles when the currently playing track changes, and it was surprisingly easy. First, wecreate a Control Point for the service we want to control. This object will emit signals when devices on the network are discovered which provide this service, so by connecting to that signal all of the discovery is handled for us.

GUPnPContext *context = gupnp_context_new (NULL, NULL, 0, &error);
GUPnPControlPoint *cp = gupnp_control_point_new (context, "urn:schemas-upnp-org:service:AVTransport:1");
g_signal_connect (cp, "service-proxy-available",
                  G_CALLBACK (service_proxy_available_cb), NULL);
gssdp_resource_browser_set_active (GSSDP_RESOURCE_BROWSER (cp), TRUE);

Now in service_proxy_available_cb we are passed a Service Proxy object to which represents a device providing the service we asked for. Service proxies can have actions invoked on them, or we can be notified when a State Variable change. There is a state variable in AVTransport called CurrentTrackMetaData but don't let that fool you: for reasons too boring to detail that doesn't cause notifications. The only interesting state variable in AVTransport is LastChange, which is basically a meta-variable which contains the name and value of the last variable which changed. Madness, I agree. This is where we come to the problem with GUPnP: it makes the protocol seem so clean and simple that when warts like this become obvious, they stand out. Anyway, we want to listen for changes to the LastChange state variable. This involves adding a notify and then subscribing to the proxy. Luckily state variables emit their current value when we subscribe to them, so we never need to fetch the current value.

static void
service_proxy_available_cb (GUPnPControlPoint *cp, GUPnPServiceProxy *proxy)
 
    gupnp_service_proxy_add_notify (proxy, "LastChange",
                                    G_TYPE_STRING, notify_cb, NULL);
    gupnp_service_proxy_set_subscribed (proxy, TRUE);
 

Believe it or not, we're actually nearly finished. Now to implement notify_cb. This is passed the variable name and a GValue containing the new value. A basic implementation is pretty simple.

static void
notify_cb (GUPnPServiceProxy *proxy,
           const char        *variable,
           GValue            *value,
           gpointer           user_data)
 
    g_print ("%s changed to %s\n", variable, g_value_get_string (value));
 

And we're done! When the program starts it discovers any devices on the network, creates proxies and watches the variables, printing them as they change. Devices can come and go, GUPnP handles that automatically. Easy as pie. Well, sort of. The string is an XML document which could contain any variable, so we need to parse it looking for a CurrentTrackMetaData node. On that node the val attribute contains an escaped XML document describing the metadata in the (and I kid you not) DIDL-Lite format. The saving grace here is that at least its partially Dublin Core, but that needs to be parsed for the title and artist information. This is all standard XML mojo, and quite boring. The end result is that my first hack application is 150 lines long, the first 100 of which are entirely devoted to XML parsing. The next step is to write a convenience library around DIDL to avoid having to parse it manually. It's not exactly a complicated task, but quite tiresome. For the curious, the full source is in this Bazaar branch. NP: Directions EP, Variou (from Acroplane I think)

This is a pretty good take on Tim Bray vs Erlang. However, I'd like to focus on something said at the end:

The fact is, all languages optimize for particular problem domains and I don't think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn't optimized for doing line-oriented I/O and it's regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.

The problem is that learning new languages is difficult for many people. They're not going to bother starting from 0 with a new language if what they've got is only 10/20% worse than the other guys. For companies, developing expertise (and trying to maintain it) in lots of languages is probably less productive than picking a few (Google only has four: Java, Python, Javascript and C++, and they're not exactly lacking in brainpower or cash). This is why "the right tool for the right job" works for things like saws and hammers, but not for complicated, idiomatic things like programming languages. Therefore, it's important that languages that aim to be widely used do lots of things pretty well, and try to avoid doing anything really badly. This is something I've always admired about Python, even if I don't use it anymore. It's a language that you can do a very wide variety of tasks with, and you can be sure there's probably some code out there already, and that Python will be ok for your task, even if it's not the best thing. Performance is a weak point compared to compiled languages, but even there, get the libraries right and things aren't *so* bad. In any case, my point isn't to bash Erlang (which I like), or put Python on a pillar (I prefer Ruby and Tcl), but to say that a widely used programming language doesn't need to be the best at everything, but it should aim to make people comfortable using it, safe in the knowledge that they can probably do most things *ok* if needs be. That's a far better situation than being able to do one thing realy well, and perform poorly at many other tasks, forcing its users to look elsewhere for solutions to those tasks. Personally, I think that for concurrency, Erlang is in a bit of a race right now - they're pretty far ahead in terms of concurrency (and also fault tolerance, but fewer people care about that), but behind in other areas (less library code). Other languages don't have as good a tools for concurrency, which isn't an easy problem. So, what will happen first - Erlang catches up elsewhere, other languages get "good enough" concurrency solutions, or a new language (like Scala) comes along and takes the lead?

I was at the September meeting of the Cooperatives SW steering group a couple of weeks ago. We had two new members (Alex Lawrie from Upstart and Alan Bonner from RadCo) and a guest from Co-operative Futures. Unfortunately, we seem to have lost our only member from a Credit Union. Our guest told us about how important it is to put information about co-operative business models into Business Link and offer paths from BL "Information and Diagnostic Brokerage" to co-operative development bodies (CDBs). I agree with that - by and large, BL were hopeless about anything other than a sole trader business when I used them (in 2000 and again in 2002/3) and knowing more about co-operative development would have saved me about a year of confused administration. (However, my then-local CDB was also a competitor, so they weren't much help even once I found them.) There are also some other ideas to connect CDBs to funding better, which the CDBs are going to develop with our blessing and bring back later. Related yet different, we were told that the Regional Infrastructure for Social Enterprise is about to launch a trade association and may exclude all co-operatives from it by mistake. Other than that, it was mostly about getting promotional materials and plans in place for the Co-operatives SW Annual Meeting in Exeter on Monday 22 October ( places available to all co-operative members).

Disclaimer: I am 100% newbie on SELinux, so any inaccuracies, mistakes or fallacies are almost sure due to this fact.

After reading Russell's latest post on SELinux, and reading the 5 minutes tutorial on SELinux I decided I should try SELinux on my laptop, too.

Now I have it enabled/enforcing/permissive/refpolicy-targeted.

First issue, hal didn't start in my GNOME session, although the hal module appears to be loaded:

bounty:/emul/ia32-linux/usr/lib/dri# semodule -l grep hal
hal 1.4.0


It seemed that gdomap indirectly required execstack. I cleared the execstack bit (or whatever it is) on libcallback.so.0.0.0 and libavcall.so.0.0.0 and gdomap started.

OTOH, oolite failed to start since it required execmem:

0 eddy@bounty ~ $ oolite
trampoline: cannot make memory executable
Aborted

And after allowing execmem it worked:
# setsebool allow_execmem=1

0 eddy@bounty ~ $ oolite
2007-10-09 01:42:04.686 oolite[26717] initialising SDL
open /dev/sequencer: No such file or directory
2007-10-09 01:42:04.789 oolite[26717] init: numSticks=0
2007-10-09 01:42:04.789 oolite[26717] CREATING MODE LIST
2007-10-09 01:42:04.789 oolite[26717] Added res 1024 x 768
...

I also seem to have some other denied messages, but I hope I'll understand this soon enough to make it work.

I would like to know if is possible to allow execmem only for oolite, and since I suspect it is, how can I accomplish this?

So, now my question is, where is the fine manual on setting SELinux? I digged the whole evening to get oolite to start.

In a previous post, I had recommended the 4130 NIST-Traceable Temperature Controller to control the temperature in a slow cooker. Unfortunately, that particular controller has a range that tops out at 60 degrees C / 140 degrees F, which is enough for cooking beef for long periods of time, but not enough for say, cooking duck confit, which for which a sous vide temperature of 80 degrees C is recommended. In addition, the 4130 is pretty expensive; almost $150. It’s possible to add a resistor to change the range of the 4130, but the temperature displayed by the controller is no longer correct, and you have manually create a conversion table between true temperature and the temperature as seen by the controller. I’ve recently come across a cheaper and better possibility, the Ranco ETC-111000-000 Temperature Controller which is only half the price and comes with a much larger working range (-30 to 220 degrees F). The price with the AC cord already wired in is $75; and the version which just has a 120VAC SPDT relay is only $60. A bit more about food safety. There has always been a lot of concern about bacteria growth and botulism, for good reason — and so therefore the recommendations for cooking temperature have a lot of safety margin in them — to the point now that the USDA recommends that steaks be cooked to at least 145 degrees F, which is well within what had traditionally been called “medium”, and chicken to at least 165 degrees F, which is enough to really destroy taste and texture. Sous vide cooking, especially some of the more low temperature variants, have raised a lot of concerns, to the point where a few years ago New York City (temporarily) banned it, causing a great outcry in the foodie community, since many top restaurants use sous vide techniques. First of all, any recommendation about internal temperatures and food safety that doesn’t also factor in time is massively oversimplifying the problem. Here is a table taken from “Food Safety Hazards and Controls for the Home Food Preparer”, published by the Hospitality Institute of Technology in 1994:

Temperature, F	Time, 5D kill	Time, 6.5D kill
130	86.42 minutes	112.34 minutes
135	27.33 minutes	35.53 minutes
140	8.64 minutes	11.23 minutes
145	2.73 minutes	3.55 minutes
150	51.85 seconds	1.12 minutes
155	16.40 seconds	21.32 seconds
160	5.19 seconds	6.74 seconds
165	1.64 seconds	2.13 seconds

This table lists the time to reduce bacteria concentrations of Salmonella and E. coli from 100,000 to 1 (5D) or 3,162,277 to 1 (6.5D). The FDA and USDA recommend cooking hamburger to 5D destruction. Since it is extremely unlikely for there to be more than 100 Salmonella organisms per gram of meat, a 5D kill will reduce Salmonella concentrations to no more than 1 organism per kilogram. So whether you cook a piece of meat to an internal temperature of 165 degrees for 1.64 seconds, or hold it at 130 degrees for 90 minutes, the effect on Salmonella and E. coli bacteria will be the same.Of course, one concern is that in many forms of cooking, particularly oven roasting and grilling, the temperature of the food as it heats up may not be even; so how do you guarantee that all parts of the food product has been brought up to the requisite 165 degrees? One way that recipe authors, fearful of liability concerns, have done so is to tell people to cook meat to much higher internal temperatures, to provide that extra safety margin at the expense of dessicated, horribly tasting turkey or chicken. But the advantage of sous vide cooking is by immersing the food in a water bath, the excellent heat conductivity of water helps guarantee that the entire body of meat will get raised to desired temperature relatively quickly. (How quickly depends on the thickness of the meat, obviously). So if you hold a roast beef that has been vacuum packed in a Foodsaver bag for five or six hours, there should be no question that all of the common bacteria has been inactivated, and that amount of time at 130 degrees F should be sufficient to inactivate 99.9 percent of all botulism toxin molecules (not there should be any in a fresh piece of meat, of course!) However, sous vide temperatures are not enough to kill bacterial spores, in particular C. botulinum, which is responsible for botulism. This requires temperatures far in excess of boiling water at sea level. For example, home canning protocols recommend holding the food product at 250 degrees F for at least 15 minutes. This is an issue in the restaurant business because very often food would be cooked sous vide, and then stored in the vacuum sealed bags for potentially weeks (yes, you could be eating an extremely expensive meal at a top-end French restaurant that had been cooked several weeks ago, and reheated just before serving; yummy, no?). If the food packages aren’t cooled quickly enough, and then allowed to warm to the danger zone, it’s possible that in the anerobic environment the C. botulinum spores could germinate and then start producing toxin. But, if you are cooking home sous vide where you are serving the food right after it has been cooked, this shouldn’t be a concern.

Bruce Schneier has just written about the Storm Worm [1] which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information [2]). I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent many possible methods of getting local root. If a user who does not have the root password (or is not going to enter it from a user session) has their account taken over by a hostile party then the attacker is not going to get local root (unless there is a kernel vulnerability). Without local root access the activities of the attacker can be seen by a user logged in on another account - processes will be seen by all user sessions if using the SE Linux targeted policy and files and processes can be seen by the sys-admin. If while a user account is 0wned the user runs “su -” (or an equivalent command) then in theory at least the attacker can sniff this and gain local root access (whether enough users do this to make attackers feel that it’s worth their effort to write the code in question is something I couldn’t even guess about). If the user is clueless then the attacker could immediately display a dialog with some message that sound urgent and demand the root password - some users would give it. If the user is even moderately smart the attacker could fake the GUI dialogues for installing updated packages (which have been in Red Hat distributions for ages and have appeared in Debian more recently) and tell the user that they need to enter the root password to install an important security update (oh the irony). In conclusion I think that if a user is ill-educated enough to want to run a program that was sent to them in email by a random person then I expect that the program would have a good chance of coercing them into giving it local root access if the user in question had the capability of doing so. Even if a Linux trojan did not have local root access then it could still do a lot of damage. Any server operations that don’t require ports 1024 (which means most things other than running a web, DNS, or mail server) can still be performed and client access will always work (including sending email). The trojan would have access to all of the user's data (which for a corporate desktop machine usually means a huge network share of secret documents). If a trojan only attempts to perform actions that SE Linux permits (running programs from the user's home directory, accessing servers for DNS, HTTP, IRC, SMTP, and other protocols - a reasonable set of options for a trojan) then the default configuration of SE Linux (targeted policy) won't stop it or even log anything. This is not a problem with SE Linux, just a direct result of the fact that in every situation a trojan can perform all operations that the user can perform - and if the trojan only wants to receive commands via web and IRC servers and send spam via the user's regular mail server then it will be a small sub-set of the permitted operations for the user! If however the trojan tries more aggressive methods then SE Linux will log some AVC messages about access being denied. If the sys-admin has good procedures for analysing log files they will notice such things, understand what they mean, and be able to contain the damage. Also there have been at least two cases where SE Linux prevented local root exploits. Finally, in answer to the original question: SE Linux will stop some of the more aggressive methods that trojans might use. But there are still plenty of things that a trojan could do to cause harm which won't be stopped or audited by SE Linux policy. When Linux gets more market share among users with a small amount of skill and no competent person to do sys-admin work for them we will see some Linux trojans and more Linux worms. It will be interesting to see what methods the trojan authors decide to use.

• [1] http://www.schneier.com/blog/archives/2007/10/the_storm_worm.html


• [2] http://en.wikipedia.org/wiki/Storm_Worm

Share This

So the new NAS is happily running Debian now, and I'll write a long blog for anyone who wants to do the same once I have one remaining problem sorted out... Avahi doesn't work. If I start Avahi on the NAS other machines see the announcement and the names it provides will resolve, but after a few minutes they fail to resolve as they timeout. Unless my router is incredibly brain-dead it can't be the cause, because the old NAS is connected in exactly the same way and it works fine. For extra fun, the NAS can't see the rest of the mDNS network. It's almost like the network driver is dropping incoming multicast packets. Before anyone asks, there is no firewall running on the NAS. Does anyone have any ideas? NP: Remembranza, Murcof

Somewhat unbelievably (to me at least) there is still wireless in my mother’s backyard and it has only gotten better and stronger. But let’s face it, writing in garden lounge chairs among the frogs, birds, sun, rain and wind are sub-optimum for thinking and writing, so I am always looking for good and, most especially, gratis wireless. I was pretty psyched to find a new cafe, Camilles Cafe that had decent looking food and proudly advertises Free WiFi. So I went there this afternoon, ordered my cafe con leche, sat down, and ran dhlcient to get my IP address and it served me one in a jiffy. I opened my xchat, said hello to my fellow chatters, and then proceeded to login to my email and I never got further than that because they disabled access to any page that requires a password. I went up to the counter to ask why and the answer I got was “porque un hacker nos ataco.” It is totally retarded that the can’t reenable whatever they turned off after adding some basic security measures. They are losing tons and mean tons of business. One quick visit to the “other” cafe down the street with free wireless Me. Starbucks shows there is much business to be made if you provide free wireless. It is Sunday and there are 12 people here with computers and people of all stripes and backgrounds and they come because the wireless is cheap and fast. Be warned: logging on to the wireless here is totally non-obvious. When you try to log in, you are routed to a corporate Centennial web page that asks for an user-id/password or asks you to create one. So you of course think that it will cost money to do so. But in fact you just create a name, password etc. and then the site never asks you for mullah (nice). There is no sign, instructions, giving you these instructions. You gotta know or you gotta ask one of your neighbors. This odd system has been in place for years and I just wonder when the only free wireless in a coffee shop (at least that I know of) will be snatched away. Hopefully never and hopefully someone else will get the bright idea that if they open another coffee shop and also provide free wireless, they will make a killing. This place is always always, and I mean always, packed. p.s.: make sure to bring headphones/music too unless you are great at working with plently of background noise, which includes the usual starbucks music (about as good as its coffee, not), people chatting, people video-chatting sans headphones, and people watching shows like South Park. It is downright cacophonous..

Hmm. Quick update of life: Last weekend Leif pushed out a third tooth. This weekend, I fed him for the first time. So far it's been Angie actually putting things in his mouth, but on a visit to Cha Ya, I fed him some miso soup. Totally fun. Our current experiment with him is to get him to sleep at night without nursing to sleep. It used to be that I could get him to sleep just by lying next to him in a dark room, and lately I haven't been able to. So, he's now nursing just before and then switching to cuddling to sleep. It's not ideal but it at least moves us from something only Angie can do to something both of us or a babysitter can do.

That's right, we're starting to think about babysitters. We don't know people here well enough that we can leave him with, but when we do, baby, there's a bottle of port with our name on it. (Yes, it's the same bottle of port I got for my 30th birthday. I didn't want to pass a sip for each of the 100 people that were there at the time, and the next major event that came along was Angie getting pregnant)

A quick geek moment: current Ubuntu Gutsy now suspends and resumes on both of my laptops with reasonable consistency. For a long time, I could suspend my Toshiba once, and the second time, it would lose keyboard but that seems to be fixed. My work laptop has suspended and resumed generally fine all along, but Network Manager still occasionally forgets the settings. This is really annoying when there's a pile of 802.1x stuff to key in. I can't reliably reproduce it, but maybe during the next Gnome cycle, I'll try to figure out why it does that. Other than that it's working really well. The wine that's in Gutsy claims to support iTunes, but it doesn't. Even if it did, it probably wouldn't work with the iPhone, but I'm sure that'll get fixed sometime. Or perhaps the lawsuit will yield something useful and make hacking it safe. Given that it's pretty trivial to get the browser into a state where it's worth power cycling the phone, I'm not willing to forgo updates in the meantime. Assuming I could do one, that is.

Lastly a happy Thanksgiving to everyone! We were attempting to meet a pile of people this weekend, but amazingly enough 4 different people ran into trouble getting here. It'll be a cozy event then.

The Haskell Hackathon in Freiburg is nearly over now. For me, it turned out to be a xmonad hackathon, as of a few days ago, xmonad is able to handle dock applications such as the gnome-panel properly (that has prevented me from looking at xmonad before).Now that the panel worked, I also wanted it s window list and workspace switcher to at least show me the state of my workspaces. This resulted in the EwmhDesktops extension. I also noted that the dock handling provided in the default Config.hs was not sufficient, as it would even treat dialogs from gnome-panel as a dock. This is fixed with the extension ManageDocks, which later got additional support to increase xmonad s border gap if an window (such as gnome-panel) has the STRUT attribute set. To closer match my old metacity keys I added support to CycleWS for going to the next/previous workspace and for moving the current window there.I had some ideas how to make the hook interface for xmonad nice, and now started to work on debian packges for xmonad: You can get and test prelimary ones.

When running SE Linux you will notice that most applications are not permitted to run with an executable stack. One example of this is libsmpeg0 which is used by the game Freeciv [1]. When you attempt to run the Freeciv client program on a Debian/Etch system with a default SE Linux configuration (as described in my post on how to install SE Linux on Debian in 5 minutes [2]) then you will find that it doesn’t work. When this happens the following will be logged to the kernel log and is available through dmesg and usually in /var/log/kern.log (Debian/Etch doesn’t have auditd included, the same problem on a Fedora, RHEL, or CentOS system in a typical configuration would be logged to /var/log/audit/audit.log):
audit(1191741164.671:974): avc: denied execstack for pid=30823 comm=”civclient” scontext=rjc:system_r:unconfined_t:s0 tcontext=rjc:system_r:unconfined_t:s0 tclass=process The relevant parts are in bold. The problem with this message in the message log is that you don’t know which shared object caused the problem. As civclient is normally run from the GUI you are given no other information. So the thing to do is to run it at the command-line (the avc message tells you that civclient is the name of the failing command) and you get the following result:
$ civclient
civclient: error while loading shared libraries: libsmpeg-0.4.so.0: cannot enable executable stack as shared object requires: Permission denied This makes it clear which shared object is at fault. The next thing to do is to test the object by using execstack to set it to not need an executable stack. The command execstack -q /usr/lib/libsmpeg-0.4.so.0.1.4 will give an “X” as the first character of the output to indicate that the shared object requests an executable stack. The command execstack -c /usr/lib/libsmpeg-0.4.so.0.1.4 will change the shared object to not request an executable stack. After making such a change to a shared object the next thing to do is to test the application and see if it works correctly. In every case that I’ve seen the shared object has not needed such access and the application has worked correctly. As an aside, there is a bug in execstack in that it will break sym-links. Make sure that the second parameter it is given is the shared object not the sym-link to it which was created by ldconfig. See Debian bug 445594 [3] and CentOS bug 2377 [4]. The correct thing to do is to fix the bug in the source (not just modify the resulting binary). On page 8 of Ulrich Drepper’s document about non-SE Linux security [5] there is a description of both the possible solutions to this problem. One is to add a line containing “.section .note.GNU-stack,"",@progbits” to the start of the assembler file in question (which is what I suggested in Debian bug report 445595 [6]). The other is to add the parameters “-Wa,--execstack” to the command-line for the GNU assembler - of course this doesn’t work if you use a different assembler. In the near future I will establish an apt repository for Debian/Etch i386 packages related to SE Linux. One of the packages will be a libsmpeg0 package compiled to not need an executable stack. But it would be good if bug fixes such as this one could be included in future updates to Etch.

• [1] http://en.wikipedia.org/wiki/Freeciv


• [2] http://etbe.coker.com.au/2006/12/08/se-linux-on-debian-in-5-minutes/


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445594


• [4] http://bugs.centos.org/view.php?id=2377


• [5] http://people.redhat.com/drepper/nonselsec.pdf


• [6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445595

Share This

The best sci-fi series for a while IMNSHO, Battlestar Galactica next and last season will start with a two-hours episode (razor) in november 24! Fortunately I'll be in USA. So say we all. :P

At Debconf, we (the i18n crowd) discussed about the NMU campaign we ran before the release of Etch (roughly from September 2006 to March 2007). We concluded that running a campaign slightly earlier in the release process would be likely to save us some work. Indeed, experience shows that the initial pings sent to maintainers often trigger uploads to fix the pending l10n issues. So, let's start thinking about it now. For those who don't remember, the rough process is described here. As one sees, it is deeply respectful for maintainers and takes great care to avoid unwanted NMUs. So, to begin, please check the list of the pending po-debconf l10n issues ranked by...a pretty complicated mathematical formula which aims to put packages which would most benefit from an upload in first position... In case one of your packages is listed near the top of that list, just consider uploading it soon. PS: of course, the mathematical formula includes a secret pondering scheme aimed at giving French translations more weight, as anyone would have guessed.

A new release with a new feature: pommed can now act as a replacement for the PC Speaker and play your favorite WAV file as the system beep. The feature is disabled by default as it’s not needed on all machines (most of the PowerPC machines have their system beep handled by the sound driver) and I guess not everybody wants it by default. You need to load the uinput driver before pommed starts for this to work. If you want your Mac to behave like a good old Mac and have it quack at you, Google for Quack.aiff and turn that into a WAV file ;)
Have fun!

A party calling themselves Oslo Byaksjon this year entered the elections, with the tagline “P parti med byen” (roughly, “On the city’s side”, or “With the city”). Their platform wasn’t horrible, and I briefly entertained the notion of voting for them. In the end I didn’t, for some important reasons; but that’s not very relevant. A Norwegian tradition is for the political parties to set up stands leading up to the election, along Karl Johans Gate (Main street, the street between the Royal Palace and the Storting (the parliament building), and this year was no exception. However, almost a month after the September 10th city elections, Oslo Byaksjon still haven’t removed the fiber boards after taking the thing apart. They’re now an orange eyesore in the middle of Oslo’s main street. Ironic! (More pictures here) Update: ZOMG, I am on Planet Debian. Hello, friends

Back around 1999, I was really interested in getting all of Debian imported into CVS (ugh!) so we could have all the benefits of pervasive version control. I've always been sad it didn't happen, especially since ubuntu did it. Although they seem to get less benefits from it than I would have thought at the time, go figure. I actually feel though that the model Debian has developed with alioth and now with VCS- fields, in which packages use version control, and debian integrates support for it without mandating it, or mandating which version control system is used, is has better legs than ubuntu's model. Ubuntu's model potentially leaves you where freebsd is now, nursing a cvs equivilant along as the world has moved on. Except, well, Debian actually picked a different version control system, and has been stuck with it for years. I refer to the diff, which is great for passing patches around by email, but not so great as a mechanism for recording the history of changes needed to debianise a package. So we have this whole set of things piled on top of the diff, like the loathsome dbs. We also have this whole set of problems in the source package format that cannot be expressed by diff and have to be messily worked around, like not being able to add/modify binary files, and not being able to (re)move files. (Wig and Pen addresses some of the worst limitations of the current format, but AFAIK noone is working on implementing support for generating Wig and Pen format packages, since doing so is unavoidably complicated.) Once I started looking at the diff in .diff.gz as a version control system, the natural thing was to think about adding support to other revision control systems, following down our path of debian supporting maintainers who choose to use a different one. So I arrived at the idea of a .git.tar.gz. Let a debian source package consist of just a .dsc and package_version.git.tar.gz, which contains only package/.git/*. Making changes to the source becomes very pleasant, since you can commit any change you like and not have to worry about how it will be repesented in the .diff.gz. And of course there's all kinds of benefits of having the history and branches and tagged upstream source available in there. Far too many benefits to list here, and only a few downsides. I look at this as very much of an evolutionary change, not a revolutionary change, to the debian source format. Most packages will continue to use .diff.gz for a long while, but packages whose maintainers chafe under that format will have another one to choose from. So, well, I implemented it. A dpkg-source that understands this format is available in the sourcev3 branch at git://kitenet.net/dpkg. I'll be posting some technical details and the patches to debian-dpkg, and I've put a FAQ about it in the wiki. A sample dpkg source package built using this is temporarily here. This demo package includes only the last 200 commits to the dpkg git repo, so it's more than 1 mb smaller than dpkg's normal .tar.gz!