Linux in the news
All in one big page
See also: last week's Kernel page.
The current kernel release remains 2.2.5. Linus has returned from his vacation and resurfaced on the mailing lists, and a 2.2.6 prepatch has shown up on the FTP site, so 2.2.6 may well be out by the time you read this. Presumably it will contain a number of the fixes found in 2.2.5ac6, which is the last "ac" patch that had been put out as this was written.
For 2.0 folks, 2.0.37pre10 has been released, see the announcement for details. This is intended to be the final prepatch before the official 2.0.37 kernel goes out.
An NFSv3 client implementation for Linux has been released by Trond Myklebust. With this release, Linux finally begins to move into current NFS technology. The initial release (announcement here) is, of course, for the adventurous only. A number of early adopters have reported improved performance; however. Lots of bugs have been fixed, and an updated version is now available for testing.
On the server side, H. J. Lu has released a new version of knfsd. This is entirely version 2 NFS, of course, but is becoming increasingly stable. Folks doing any sort of serious NFS serving on 2.2 Linux boxes should get this version of the server. See the announcement for details.
Other releases this week include:
Capabilities continue to generate a lot of discussion. See last week's issue for an overview of the disagreement; the situation has not changed much.
It does seem to have evolved, however, into a more general difference of opinion on how security in Linux systems should work. Proponents of a "pure capabilities" system see a world in which there are no more privileged users, the root account no longer exists, and UID 0 is just another user account. In this world, all privileges ("capabilities") belong to specific programs; users differ only in the degree of access they have to these programs.
In the absence of a root user, capability schemes which depend on setuid root files will not work. So the "pure capabilities" folks support separating the storage of capabilities from the programs they apply to and storing them as metadata in the file system. A capability-based system will be a very different world, so the fact that a lot of programs will break under this model is just part of the pain that has to be endured to get there.
The other camp sees capabilities as a way of increasing security by reducing the privileges of server programs and the like. They see no need to abolish the root account, and no need to adopt schemes that break more of the system than is absolutely necessary. These folks argue for putting capabilities into the actual executable files of the programs they apply to, and using the setuid or sticky protection bits to cause the system to apply those capabilities.
This is an important discussion, it marks an important fork in the road to the future of Linux. It is unfortunate that it is not more conclusive. It seems like time for Linus to weigh in and indicate which way the wind is blowing.
Section Editor: Jon Corbet
April 15, 1999