Linux in the news
All in one big page
See also: last week's Kernel page.
Linus still has not resurfaced on linux-kernel, though there are now some signs of his continued existence. In particular, 2.3.19 was released this week, thus far without any sort of announcement. There is still no sign of the much-awaited 2.2.13 stable kernel as of this writing, though a release should be happening before too long. Meanwhile, Alan Cox's 2.2.13 pre-patch is up to 2.2.13pre15.
The "final" version of "The Wonderful World of Linux 2.4" has been released by Joe Pranevich. This documentdescribes the new features to be found in the upcoming stable kernel release.
Access control lists (ACLs) for Linux are one of the missing security features that Microsoft criticized in its "Linux Myths" document. ACLs allow for more control over file access by allowing the granting (or removal) of permissions to individual users and groups. In even slightly complicated situations, this kind of control over file access becomes important; that is why many operating systems have had ACLs for decades.
A number of ACL projects for Linux exist. Perhaps one of the most advanced is the Posix ACLs for Linux project, led by Andreas Grünbacher. This group has set out to implement ACLs conforming to the draft Posix standard. Their goals include the creation of an easy and well-defined framework so that ACLs can be added to any filesystem, the ability to support existing ACL structures in other filesystems (NTFS, AFS, etc.), and, of course, a stable ext2 implementation.
The Posix ACLs project has produced working code, but they have run up against a snag. Deep filesystem code like this requires a great deal of testing before one can even consider submitting it for inclusion into the mainline kernel. There just have not been enough people testing out the ACL code. Until people run it and find the problems, the confidence just is not there to press forward.
If you would like to help out with Linux kernel development, but have not been able to dig into the code, here is your chance. Grab the ACL patch, run it, and send your experiences back to the development team. With some help, this project can move forward and close up one of the big holes in the Linux security model.
USB device names and numbers are under discussion again. The Universal Serial Bus presents certain naming problems which stretch the Linux notion of devices toward the breaking point.
Allocation of device numbers is one of the problems that comes up. A typical /dev contains a lot of "devices" which do not actually exist on the system. The device major and minor numbers (and, incidentally, the names in /dev) have all been preallocated and are there waiting for the device to show up.
USB's flexible way of dealing with devices makes this static allocation hard to maintain. A USB port can contain up to 127 devices, and many systems already have more than one such port. Consider, for example, an ISP that would like to populate a system with dozens of USB modems. That actually looks like a reasonable and cost-effective way to set up a modem bank. But how can Linux allocate enough device numbers to accommodate that application while still allowing for all the other possible USB device configurations?
Clearly device management on the USB has to be a more dynamic thing. So, of course, some people immediately proposed devfs as the solution to this problem. The conversation then wandered into the usual devfs debate; we have been there before.
Whether or not devfs is involved, some sort of solution to dynamic devices needs to be found. The final solution is likely to involve some sort of hook into the kernel whereby a user-space daemon process is notified when a device is added to (or removed from) the USB. That process can then tweak things in /dev to its heart's content, taking into account any local policy (i.e. device permissions) that may be applied.
Another network security vulnerability was found this week by Andrey Savochkin. This one happens at the Internet Protocol (IP) level, and takes advantage of the fact that the generation of IP packet identifier numbers is done in a predictable way. Normally the ident field is used to properly reassemble fragmented packets, but a suitably sneaky adversary can use this vulnerability to slide in spoofed packets from another source.
There is still some discussion over the proper fix for this problem. Currently no exploits are known to exist.
Other patches and updates released this week include:
Section Editor: Jon Corbet
October 7, 1999