Readers sound off.
Free Enhydra?

The August 2001 LJ's At the Forge is about a feature of Enhydra. Enhydra is commercial software, based on Java, which is commercial software. As far as I can see, there is no mention of Linux or anything specific to Linux in the article. It would not be out of place in a magazine called Web Automation, but I fail to see why it belongs in a magazine devoted to Linux, and more generally, to free software.

—Carl Fink

Reuven replies: While Java isn't free software, many web developers want or need to use Java in their work. I cannot change the Java license, but I can encourage Java developers to use an open-source operating system (Linux) and an open-source application server (Enhydra). So far as I understand it, there are two different ways to get Enhydra. The first is to obtain the core Enhydra application server, which is freely downloadable and distributable. This includes XMLC, DODS, super servlets and all that other stuff. The license agreement for this is indeed open source, despite what you might read elsewhere on the Enhydra web site. Here are three URLs about the licensing scheme: www.enhydra.org/aboutEnhydra/index.html, enhydra.enhydra.org/software/license/rationale.htm and enhydra.enhydra.org/software/license/opl.html. The second way is to get the Lutris EAS (Enhydra Application Server), which is a commercially packaged and tested version of the open-source stuff. I believe that you pay $995 US (or so) per CPU for EAS, but you're paying for the support, not for the server itself, in a twist on the open-source model. You could also argue that my article about PostgreSQL wasn't specifically about Linux, but the fact is that there are many people interested in using that database on Linux. For better or worse, there are lots of Linux devotees who also want to be able to use Java. Indeed, as someone who does web development on Linux every day (and many nights) of the week, I'm happy to know that I can now talk to clients about a serious Java and EJB solution that goes above and beyond Jakarta-Tomcat.

Bug-Eaten Exploits

I really enjoyed the article “Loadable Kernel Module Exploits” by William Benton in the September 2001 issue of Linux Journal. I know that such articles are not meant to be exhaustive, but there is one bug in the Checking and Logging Function Listing on page 26 that I consider to be critical. The code hooks into the sys_call_table by saving the current address of SYS_write and replacing it. It unhooks by putting back the saved address. The bug is if there is more than one such hook. If another module hooks the SYS_write entry after this module, then an rmmod is done on this module, and the other module will become unhooked.

An even worse scenario is possible: 1) Module A is insmod-ed and hooks SYS_write. SYS_write points to wrapped_write in module A, orgwrite points to the previous contents (assume it is the normal entry). 2) Now module B does the same. SYS_write points to, say, modified_write in module B, orgwrite points to wrapped_write in module A. 3) Module A is rmmod-ed. SYS_write now contains the original SYS_write value. But this means that modified_write in module B is now bypassed. 4) Now module B is rmmod-ed. The cleanup_module in module B will restore the SYS_write table entry to point somewhere where module A used to reside. 5) Linux will most likely crash.

Unfortunately, I am not really a kernel hacker, so I don't know how I could tell the rmmod function that I don't want to be removed. To be safe, you would need to rmmod in the reverse order that you insmod-ed. I don't know enough about Linux to say how this could be accomplished.

—John McKown

Benton replies: You are correct; the situation you describe can be a problem for production code if a system administrator is not careful. I had not assumed that it would be a serious issue in example code (or in production code with a vigilant system administrator), but it is good to identify possible pitfalls in kernel programming. One (simple) solution is to be careful what you load and unload and in what order. As the old joke goes: “Doctor, it hurts when I do this!” “Well, don't do that, then!”. There are plenty of ways to crash your system poking around in the kernel, and it's best to avoid all of them once you've identified them. In all seriousness, these problems will exist as long as Linux does not provide a mechanism for registering changes to the system call table. I don't think they're horribly serious, since a degree of care on the part of the user can prevent a crash. However, there is a workaround that can give you some basic stability: in cleanup_module(), be sure to check whether the system call table entry that you're about to restore is what you think it should be. If not, issue a warning and invoke the sync() system call before modifying the system call table. That will minimize the damage in the event of a crash. As an alternative (and more difficult) solution, you could replace the create_module system call in the first module you load, wrapping it with one that provides some sort of versioning system for the system call table in a static stack or deque. I'll leave implementing that as an exercise for the reader.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState