[7428] in bugtraq

home help back first fref pref prev next nref lref last post

Re: EMERGENCY: new remote root exploit in UW imapd

daemon@ATHENA.MIT.EDU (der Mouse)
Tue Jul 28 19:17:23 1998

Date: 	Tue, 28 Jul 1998 14:09:36 -0400
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@NETSPACE.ORG

> Beware of the Dijkstra phenomenon.

> The phenomenon is that immodular code seems more ``productive'' than
> heavily modularized code.  You can read or write many more lines per
> hour of malloc(), strcpy(), free() than of unfamiliar high-level
> routines.

This is actually "you can read or write many more lines per hour of
familiar calls than unfamiliar calls"; if you're not familiar with
malloc(), strcpy(), and free(), you can't churn them out very fast
either - at least not with even the minimal correctness most programs
exhibit.

> Of course, the modular code ends up being _much_ smaller.

This is far too dogmatic a statement.  It is true in many
circumstances, but it is also false in plenty of other circumstances.

I recently wrote a program to check if a file had been touched recently
(for a suitable value of "recently") and if not, to restart the daemon
that should have been touching it.  The code calls only a handful of
routines more than once: fprintf (3 calls), exit (6 calls), open (2),
dup2 (3), close (2), strerror (3).  (The routines called only once are
lstat, gettimeofday, fork, ioctl, setpgrp, chdir, unlink,
getdtablesize, execle.)  I don't for a moment believe using "modular
code" would have made this program "_much_ smaller".  Indeed, I *am*
using a "modular" module, namely stdio, and my offhand guess is it's
responsible for more than half the program's size (when linked static -
otherwise stdio's contribution isn't easy to work out; the static
version is over four times the size of the non-static version, on disk).

The modular code usually ends up being slower, too.  Not enough slower
to matter, in many circumstances, but it's something to keep in mind.

> It also lets you independently check the correctness of each module;
> this scales to arbitrarily large systems if the modules remain small.

It also means that a missed bug affects an arbitrarily large proportion
of the system as a whole, of course.

                                        der Mouse

                               mouse@rodents.montreal.qc.ca
                     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

home help back first fref pref prev next nref lref last post