See also: last week's Kernel page.

Kernel development

Discussion in general was slow in linux-kernel this week; the stable kernel seems to be really stabilizing and there's less to talk about. The GNU/Linux debate filled in a lot of volume without adding much in the way of new understanding or new code. Gluttons for punishment can check out Stallman's it can ruin your whole decade note, Jim Gettys' response, and Stallman's response to the response which spells out his view on how we came to have a free operating system.

Newsflash! The Kernel Newsflash Page is maintained by Richard Gooch in an attempt to cut down on some of the traffic in linux-kernel. That page is kept current with known problems with the current release; the idea is that people should check there before asking about a problem on the mailing list. (Thanks to Horst von Brand).

Journaling is coming. Stephen Tweedie let slip that he expects to have his journaling file system code ready for testing in about four weeks.

How best to represent capabilities for executables? Capabilities are the Linux implementation of the old "privileges" concept first used by other operating systems many years ago. The idea is to replace the current privilege scheme - where, if you are root, you can do anything - with a more fine-grained scheme. Thus, for example, a network daemon which needs to be able to bind to a low-numbered socket would be given a capability to do just that, and no more. If somebody finds a way to compromise that daemon, they have gained very little in the way of additional access to the system.

It was mentioned this week that work is proceeding on integrating capability masks into the upcoming ext3 file system. The file system would thus support extending the setuid scheme to a "setcapability" mechanism, allowing trusted executables to be installed with the needed capabilities. This seems like a logical extension of how things have been done in the Unix world for years.

But is it? A vocal group of dissidents, with Albert Cahalan as its most visible member, is pushing a different scheme. Why not embed a "capability header" into the executable itself? The kernel would read capabilities from that header before running the program, but only if it is installed setuid root.

There are a number of advantages that proponents of this scheme can point to. Hacking filesystems is always a bit scary, and this approach eliminates the need for filesystem changes. Capability headers will be automatically backed up and restored by programs like dump and tar without modification. If the system is booted with an older, pre-capability kernel, the setuid binaries should still be able to function in the old mode. This method will work over NFS. And so on.

Arguments in the other direction tend to be more vague. There is a certain sort of "bolt-on kludge" nature to the capability headers that some don't like. And there is some discomfort with the idea of an executable telling the system what its capabilities should be, even if it appears that this could be done safely.

In the end, of course, this is a 2.3 issue. Even though 2.2 has some basic capability support, the needed changes to the filesystem and/or the executable loader are more than are likely to be accepted into a stable kernel series. (See also: John Wojtowicz's description of how capabilities work).

A new version of the Framebuffer HOWTO has been released by Alex Buell.

Section Editor: Jon Corbet

For other kernel news, see: LinuxHQ Kernel traffic

Next: Distributions