Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 29 Feb 2024 22:46:08 GMT, Scott Lurndal wrote:
>
>> In the early unix days, we had the fork bomb:
>>
>> https://en.wikipedia.org/wiki/Fork_bomb
>
>It still works.

That depends entirely on how the administrator has
configured the system.

$ ulimit -a
nproc (-u) 1024

In article <G5ANN.756840$p%Mb.143470@fx15.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Thu, 29 Feb 2024 22:46:08 GMT, Scott Lurndal wrote:
>>
>>> In the early unix days, we had the fork bomb:
>>>
>>> https://en.wikipedia.org/wiki/Fork_bomb
>>
>>It still works.
>
>That depends entirely on how the administrator has
>configured the system.
>
>$ ulimit -a
>nproc (-u) 1024

A funny story about fork bombs.

I used to use a public access Unix system called "grex", based
in Ann Arbor, MI, USA (a place I've never been). It was a very
interesting experience to use a "real" timesharing machine. But
because they gave accounts to anyone who logged in and signed up
(there was a self-service account creation program that ran if
you logged in as `newuser`), there was a lot of abuse. Of
course ye olde fork bomb made a frequent appearance; to deal
with this, some staff members wrote a "fork bomb killer".

At the time I started using it, Grex ran on an aging SPARC
machine running a heavily customized instance of SunOS 4. The
fork bomb killer was implemented as a loadable kernel module:
when installed, it overwrite the entry for SYS_fork in the
kernel syscall table, and jumped to a new handler. That tried
to run the real fork, and if it failed, it incremented a
per-user count of recent fork failures; that count was decayed
over time via a periodic callout to a maintenance function.
Anyway, if the "failures over time" count exceeded some
threshold, the code walked the process table and killed any
process with owned by the current user. Incidentally, if the
kernel module was uninstalled, it put back the original fork
handler. I'm glossing over some details, of course (for
instances, superuser processes were exempt from this behavior)
but that's how it worked, to a first order approximation.

Interestingly, there was a bug: the code did not account for
`vfork`. When I pointed this out, I got back a gruff reply from
the author saying, "you can't write a fork bomb around vfork:
the parent is suspended until the child exits." Evidently, the
person who wrote this misunderstood the semantics of `vfork`;
it's true that the parent is suspended, but only until _either_
the child exits _or_ exec's something: and obviously a `vfork`
based fork-bomb could simply `exec` itself in the child. I
wrote a proof of concept that worked as expected.

To my knowledge, that was never exploited.

- Dan C.

On 2024-03-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> My filling-up-disk-space story involves, not something my code did, but
> something the vendor’s compiler did.
>
> This was DEC’s COBOL compiler on a PDP-11/70 running RSTS/E, during my
> undergrad days.

<snip>

Speaking of COBOL compilers, here's one that isn't so much a
filling-up-disk-space story as a filling-up-name-space story.

We were porting mainframe COBOL programs to a Unix box, using
MicroFocus COBOL. The compiler worked quite well, but it had
one irritating quirk: when sorting data with the COBOL SORT
verb, compiled programs created ridiculously small work files
on disk. We were sorting a large file, and when the process
died it had created about 12,000 work files.

But that's not the best part. The work files were named something
like SORTnnn.WRK. See where this is going? Yep, the sequence
number wrapped around. But not in the way you might think: the
high-order digit bumped from 9 to a semicolon, then a colon,
and so on through the ASCII code table until it wrapped around
to NUL and kept going. It took some time to clean up the mess -
after which we dug through the documentation until we found an
override for the work file size.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On Sat, 30 Mar 2024 17:00:58 GMT, Charlie Gibbs wrote:

> We were porting mainframe COBOL programs to a Unix box, using
> MicroFocus COBOL. ...
>
> The work files were named something like SORTnnn.WRK.

What an odd limitation. Even the earliest Unix systems allowed 14-
character file names.

> ... when the process died it had created about 12,000 work files.

That wouldn’t be so bad, if they were all in one temporary directory. One
quick “rm -rf” and it’s over.

Decades ago, I created a system for a client that involved generating
custom movies for their customers, according to a template which could
specify fixed parts (the same for all customers) and variable parts (based
on video footage unique to each customer). When the video footage was
uploaded into the system, my code split it into individual JPEG frames, so
that I could do frame-accurate reassembly into the final movie. (FFmpeg
was the workhorse for all the processing, of course.)

I would end up with something like 100,000 JPEG frame files in a single
directory. The Linux system (and command-line tools) coped with it just
fine; just don’t try opening such a directory in any GUI file manager!

On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Sat, 30 Mar 2024 17:00:58 GMT, Charlie Gibbs wrote:
>
>> We were porting mainframe COBOL programs to a Unix box, using
>> MicroFocus COBOL. ...
>>
>> The work files were named something like SORTnnn.WRK.
>
> What an odd limitation. Even the earliest Unix systems allowed 14-
> character file names.

I probably misremembered the exact file name. It might have been
longer - but the sequence number was much too short.

>> ... when the process died it had created about 12,000 work files.
>
> That wouldn’t be so bad, if they were all in one temporary directory. One
> quick “rm -rf” and it’s over.

Unfortunately, they were not; they were in the same directory as
our data files. Deleting files with a NUL (SOH, STX...) in the name
without disturbing other things took a bit of care - one slip of a
wild card and we'd have been reaching for our backup.

> Decades ago, I created a system for a client that involved generating
> custom movies for their customers, according to a template which could
> specify fixed parts (the same for all customers) and variable parts (based
> on video footage unique to each customer). When the video footage was
> uploaded into the system, my code split it into individual JPEG frames, so
> that I could do frame-accurate reassembly into the final movie. (FFmpeg
> was the workhorse for all the processing, of course.)
>
> I would end up with something like 100,000 JPEG frame files in a single
> directory. The Linux system (and command-line tools) coped with it just
> fine; just don’t try opening such a directory in any GUI file manager!

Yes, it wasn't the number of files per se (although unnecessarily large
numbers of files can be unwieldy). But the fact that the compiler would
generate code which created such outlandish file names without some sort
of error check was rather tacky.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On Sun, 31 Mar 2024 02:17:58 GMT, Charlie Gibbs wrote:

> On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> That wouldn’t be so bad, if they were all in one temporary directory.
>> One quick “rm -rf” and it’s over.
>
> Unfortunately, they were not; they were in the same directory as our
> data files.

That sounds like Micro Focus didn’t have a clue about basic Unix
conventions; surely the /tmp directory existed back then?

(Quick check) Couldn’t find a mention of any temporary files/directories
in Unix 7th Ed docs, but System V Release 1 (dated January 1983) mentions
functions for creating temporary file names, and has this in stdio.h:

#define P_tmpdir "/usr/tmp/"

In article <qJ3ON.124720$_a1e.14467@fx16.iad>,
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Sat, 30 Mar 2024 17:00:58 GMT, Charlie Gibbs wrote:
>>
>>> We were porting mainframe COBOL programs to a Unix box, using
>>> MicroFocus COBOL. ...
>>>
>>> The work files were named something like SORTnnn.WRK.
>>
>> What an odd limitation. Even the earliest Unix systems allowed 14-
>> character file names.
>
>I probably misremembered the exact file name. It might have been
>longer - but the sequence number was much too short.
>
>>> ... when the process died it had created about 12,000 work files.
>>
>> That wouldn’t be so bad, if they were all in one temporary directory. One
>> quick “rm -rf” and it’s over.
>
>Unfortunately, they were not; they were in the same directory as
>our data files. Deleting files with a NUL (SOH, STX...) in the name
>without disturbing other things took a bit of care - one slip of a
>wild card and we'd have been reaching for our backup.

If one knew the pattern of temporary file names, surely one
could write a small program that simply followed it? Something
like:

#include <stdio.h>
#include <string.h>
#include <unistd.h>

int
main()
{ int i;
char fn[12];

strcpy(fn, "SORTnnn.WRK");
for (i = 0; i < 12000; i++) {
fn[6] = i % 10;
fn[5] = (i / 10) % 10;
fn[4] = i / 100;
unlink(fn);
}

return (0);
}

>[snip]
>
>Yes, it wasn't the number of files per se (although unnecessarily large
>numbers of files can be unwieldy). But the fact that the compiler would
>generate code which created such outlandish file names without some sort
>of error check was rather tacky.

Presumably this wasn't the compiler inserting that code per se,
but rather causing the program to link against some library that
did so. It would have been better to defer to a C library
function like `mktemp` (available since 7th Edition Unix), but
there's always been an impedence mismatch between the COBOL and
Unix worlds, it seems.

- Dan C.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sun, 31 Mar 2024 02:17:58 GMT, Charlie Gibbs wrote:
>
>> On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> That wouldn’t be so bad, if they were all in one temporary directory.
>>> One quick “rm -rf” and it’s over.
>>
>> Unfortunately, they were not; they were in the same directory as our
>> data files.
>
>That sounds like Micro Focus didn’t have a clue about basic Unix
>conventions; surely the /tmp directory existed back then?

Sounds like you're drawing a false conclusion based on a single
unverified anecdote.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Sun, 31 Mar 2024 02:17:58 GMT, Charlie Gibbs wrote:
>
>> On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> That wouldn’t be so bad, if they were all in one temporary directory.
>>> One quick “rm -rf” and it’s over.
>>
>> Unfortunately, they were not; they were in the same directory as our
>> data files.
>
>That sounds like Micro Focus didn’t have a clue about basic Unix
>conventions; surely the /tmp directory existed back then?

Of course it did. There could be many reasons not to use /tmp even
leaving aside the very permissive access restrictions on /tmp.

Programs that use the standard temporary file library functions
(e.g. mktemp, mkstemp, tempnam, tempfile, tmpnam) would rely
on the TMPDIR environment variable to select the temporary
directory location. If not set, an implementation defined
value would be used (generally /tmp or /var/tmp).

Node that disks in those days were pretty small (10MB to 200MB)
and the consequences of filling /tmp when it is on the root
filesystem were not pretty.

On Sun, 31 Mar 2024 16:18:32 GMT, Scott Lurndal wrote:

> Programs that use the standard temporary file library functions (e.g.
> mktemp, mkstemp, tempnam, tempfile, tmpnam) would rely on the TMPDIR
> environment variable to select the temporary directory location.

In my research, that wasn’t true back around the time of AT&T System III,
or System V Release 1.

In article <uuboov$4ks$1@reader1.panix.com>,
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <qJ3ON.124720$_a1e.14467@fx16.iad>,
>Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>On 2024-03-30, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Sat, 30 Mar 2024 17:00:58 GMT, Charlie Gibbs wrote:
>>>
>>>> We were porting mainframe COBOL programs to a Unix box, using
>>>> MicroFocus COBOL. ...
>>>>
>>>> The work files were named something like SORTnnn.WRK.
>>>
>>> What an odd limitation. Even the earliest Unix systems allowed 14-
>>> character file names.
>>
>>I probably misremembered the exact file name. It might have been
>>longer - but the sequence number was much too short.
>>
>>>> ... when the process died it had created about 12,000 work files.
>>>
>>> That wouldn’t be so bad, if they were all in one temporary directory. One
>>> quick “rm -rf” and it’s over.
>>
>>Unfortunately, they were not; they were in the same directory as
>>our data files. Deleting files with a NUL (SOH, STX...) in the name
>>without disturbing other things took a bit of care - one slip of a
>>wild card and we'd have been reaching for our backup.
>
>If one knew the pattern of temporary file names, surely one
>could write a small program that simply followed it? Something
>like:
>
>#include <stdio.h>
>#include <string.h>
>#include <unistd.h>
>
>int
>main()
>{
> int i;
> char fn[12];
>
> strcpy(fn, "SORTnnn.WRK");
> for (i = 0; i < 12000; i++) {
> fn[6] = i % 10;
> fn[5] = (i / 10) % 10;
> fn[4] = i / 100;

The above three 3 lines should all, `+ '0'` obviously.

- Dan C.

> unlink(fn);
> }
>
> return (0);
>}

- Dan C.

In article <uuciq3$20eve$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 31 Mar 2024 16:18:32 GMT, Scott Lurndal wrote:
>
>> Programs that use the standard temporary file library functions (e.g.
>> mktemp, mkstemp, tempnam, tempfile, tmpnam) would rely on the TMPDIR
>> environment variable to select the temporary directory location.
>
>In my research, that wasn’t true back around the time of AT&T System III,
>or System V Release 1.

Of course, the person who told the story never said that they
were using Sys3 or SVR1; that was purely your speculation.

- Dan C.