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.
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.
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.
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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
|ServersCheck's Thermal Imaging Camera Sensor||May 25, 2016|
|Petros Koutoupis' RapidDisk||May 24, 2016|
|The Italian Army Switches to LibreOffice||May 23, 2016|
- Secure Desktops with Qubes: Introduction
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- CentOS 6.8 Released
- Linux Mint 18
- The Italian Army Switches to LibreOffice
- Chris Birchall's Re-Engineering Legacy Software (Manning Publications)
- ServersCheck's Thermal Imaging Camera Sensor
- Petros Koutoupis' RapidDisk
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide