See also: last week's Back page page.

Linux Links of the Week

Section Editor: Forrest Cook

This week in history

One year ago (December 30, 1999 LWN): LWN took a close look at the LinuxOne amended S-1 filing, and noted some suspicious claims within. Despite the large wave of Linux based IPOs going on at the time, that one failed to materialize.

The development kernel was version 2.3.35 and the stable kernel was still version 2.2.13, but the fix of a major IDE bug would allow version 2.2.14 to move forward. Support for the IBM S/390 was to be included in version 2.2.14. The inclusion of the kernel based web server, khttpd, was debated. The discussion centered on whether adding the complexity of a web server to the kernel was justifiable, even if it produced an incredibly fast web server.

Tiny Linux, intended for small, obsolete computers, was released. Version 1.0 came out in April, 2000 and the project is still active.

LWN mentioned a Salon article that questioned the stability of the Linux and dot com stock market frenzy: "Sooner or later, dot-com mania must be headed for a fall -- whenever you see this many lemmings gathered together in one place, you just know a steep cliff has got to be nearby. Could the rush to invest in companies which base their business models on free software be the last straw? Certainly, many observers who have long looked askance at the last few years of Internet insanity have seized upon the VA Linux IPO as just the latest, freakiest example of how crazy things are getting. "

Last, but not least, the dark gloom of impending disaster loomed heavily over sys-admins and programmers everywhere, just a few hours until all hell would break loose due to zillions of unfixed Y2K Bugs. All of the advance work paid off and computers all around the world sailed smoothly into year 19100.

Letters to the editor

Date: Thu, 21 Dec 2000 00:43:31 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
To: letters@lwn.net
Subject: Yet more on Elevator algorithms and write ordering

I'm afraid there is considerable confusion over write ordering in a
filesystem.  The confusion stems from an assumption that dependant
operations are queued to the disk device all together.  This assumption
is not true of FFS with softupdates.  FFS with softupdates turned on will
queue all *NON* dependant buffers to disk all at once and doesn't care
in the least whether the kernel, the disk device, or the physical disk
itself reorders the writes.  Dependant buffers are not queued until
non-dependant buffers have completed their I/O's.  FFS without
softupdates will use synchronous writes where necessary to (try to) ensure
that dependant buffers are not queued until after such I/O's have completed.
EXT2FS is roughly similar to FFS.  However, both EXT2FS and FFS (without
softupdates) have cases related to directories, inodes, and file blocks
where *NO* write ordering is correct even if you do things synchronously.
Filesystems are more complex then they seem.  Softupdates deals with these
interdependant cases by actually unrolling portions of the buffers when
writing them to disk to guarentee consistency on-disk, allowing it to
operate almost completely asynchronously without endangering the filesystem 
A log-structured filesytem deals with such cases by writing a sequential
log, but there is nothing preventing even a log structured filesystem from
writing a bunch of log blocks in random order as long as it doesn't try
to recover past any holes created due to a crash or commit the file 
structure until after the (asynchronous) log block I/O has completed.

What this means is that a kernel, disk device, and physical disk should
be allowed to reorder blocks however they please.  It is up to the filesystem
code to handle dependant operations.

						-Matt

Date: Thu, 21 Dec 2000 10:44:44 +0000
From: Edmund GRIMLEY EVANS <edmundo@rano.org>
To: letters@lwn.net
Subject: problems in /tmp

You'll probably get a lot of letters like this one ...

http://lwn.net/2000/1221/security.php3:

> Into this model was introduced /tmp, a shared directory to which
> anyone had write privileges and the ability to delete files created by
> other users.

Since it is amazing how many otherwise experienced people don't know
about the "sticky bit" on directories, you really should have
mentioned here that /tmp is usually created with permissions 1777,
which means it is "append-only": you can't delete other people's
files.

This would also have been a good place to educate some of your readers
about what exactly the "problems in /tmp" are. AFAIK, the main problem
is a "symlink attack": if an attacker can guess that a program might
open the file /tmp/foo for writing, they can create a symbolic link
from /tmp/foo to /etc/passwd, say. If the program is running as root,
it overwrites the password file, unless the program was clever enough
to use O_EXCL, but even then, there may be a possibility for a
denial-of-service of attack. See the man pages for mktemp and mkstemp.

On SCO UnixWare a brute-force solution to this problem is used: the
kernel does not allow symbolic links to be created in a directory with
the sticky bit set which does not belong to the caller. I don't know
of any legitimate application that require symbolic links in /tmp, so
this solution should perhaps be considered as an option for Linux.

Edmund

Date: Thu, 21 Dec 2000 11:09:18 +0000 (GMT)
From: Joey Maier <maierj@home.com>
To: lwn@lwn.net
Subject: to: Liz Coolbaugh 

Hi Liz,

First off, thanks for the good work.  You do a great job with the
security page at LWN.  I especially like your editorializing of
bugtraq threads...this week's comments on the /tmp discussion is a
great example.  I stopped following the thread (and the offshoots 
from it) after the first few posts seemed to say the same thing. 
If you hadn't linked to it in  LWN, this would have caused me to 
miss Kris Kennaway's post.  Anyway, I really like your work, and
I appreciate the fact that you don't snub OpenBSD users ;-)

WRT, the Kaspersky Lab virus review, you said:
>...or, perhaps, it's the fact that it takes a little more than 
>a bogus email attachment in the Linux environment...? 

I suspect that you made the above comment because the email attatchment 
can only run in the context of the user reading the mail, and that user 
should not be root.  While this is correct, it simply means that 
malware is limited in the amount of damage that it can do to the system
configuration.  A malicious program in a unix environment could still
destroy all of the files of the user.  Most corporate environments have 
decent backup policies for end users, but home users typically don't back
up files as often as they should, and a piece of malware that destroyed 
local user files could be very nasty for them.  

It is also important to note the increase in the tendancy for unix 
desktop user to prefer HTML-rendering mail clients.  Many of these
clients - especially the ones that are incorporated into a browser - 
may have active scripting vunerabilies that could allow manipulation
or deletion of the user's local files.

I suspect that the reason we have not seen more email-born malware 
in the unix environment is not due to the slightly limited scope
of the damage that can be done.  (Loss of data can be enough of
a problem, even if the system configuration is unharmed.)  Instead,
I suspect that the currently heterogenious use of email clients make 
it more difficult to write a virus that will affect a large number 
of people in the way the Outlook-dominated Windows platform can be
affected.  

If the *nix world starts to be predominated by a single email client,
it will start to attract malware authors.  This is especially true if
the client is HTML/active scripting aware.  Unfortunately, noone seems
to be taking this seriously, and I have not seen any viable solutions
offered.

--
	"When you understand UNIX, you will understand the world.
	 When you understand NT....you will understand NT" - Richard Thieme
http://www.slothnet.com - is currently unavailable :(

Date: Thu, 21 Dec 2000 11:13:20 -0500
From: Joe Louderback <jlouder@wfu.edu>
To: letters@lwn.net
Subject: Defamation of Fortran

In this forum Mr. Kastrup took Linus Torvalds to task for incorrectly
claiming arrays in Pascal start at 1.  He then wrote, "Most probably Mr.
Torvalds is confusing Pascal with Fortran which indeed has its arrays
starting at 1."

Ahem.

real     atone(50)
integer  atminusthree(-3:50)
logical  atsix(6:50)


Joe Louderback, itinerant physicist and occasional Fortran programmer

Date: Tue, 26 Dec 2000 13:04:42 -0800
From: Davina Armstrong <davina@lickey.com>
To: letters@lwn.net
Subject: Rick Collette's "petition" to British Telecom

I was very interested in your coverage of British Telecom's patent
infringement lawsuit against Prodigy (LWN 12/21/00).  I happily clicked
on the link to Rick Collette's "petition" to British Telecom, thereby
myself infringing upon their patent (or at least contributing to your
infringement).  I was anxious to add my signature to what I assumed
would be a petition to British Telecom urging them to drop their absurd
lawsuit.  Instead, I found the following:

"British Telecom is claiming they own the rights to the Hyperlink.
That's saying that everything you click on a website, the method used to
bring you from one page to another, belongs to them. 

They are currently suing Prodigy for this, and it's only going to
worsen. We must stand up and put a stop to this craziness. 

The signatures collected here will be sent to the Linux Journal,
deepLINUX, MSN, and any other media outlet that I can think of."

This is *not*, in fact, a petition.  This is merely a statement of
fact.  Why would anyone sign it?  Webster's Dictionary defines a petion
as "1 a solemn, earnest supplication or request to a superior or deity
or to a person or group in authority; prayer or entreaty" OR "2 a formal
writing or document embodying such a request, addressed to a specific
person or group and often signed by a number of petitioners".

This "petition" is not addressed to British Telecom and does not
actually make any request.  When someone starts a real petition to
British Telecom about this issue, I will be more than happy to add my
signature to it.

Regards,
Davina Armstrong