Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.24/text0059.txt

Text File | 1991-09-03 | 7.1 KB | 153 lines

Submitted-by: [e-mail] (Dan Bernstein)

In the referenced article, Chuck points out that POSIX invented sessions
because they wanted to fix job control. I'm quite aware of this: when I
was complaining about sessions a while back Marc Teitelbaum showed me
what the discussion had been like. There's just one problem.

In POSIX, job control is an option. Sessions aren't. I defy any POSIX
supporter to defend this.

(My guess, btw, is that the committee was thinking about tty security,
and thought that by adding POSIX sessions they could solve the problems.
Indeed, published claims by Convex, Sun, and even CERT would lead most
people to believe that this is true. It's not. POSIX sessions don't help
tty security one bit.)

Even without sessions in the way, POSIX job control is not backwards
compatible. It's missing some BSD features and it added some others.
(For instance, a BSD program can be in the foreground on one terminal
and the background on another. Under POSIX a process is either in the
foreground or in the background [with respect to its controlling
terminal], and access to other ttys simply doesn't have job control.
This ``feature'' broke emacs and screen, among other programs.)

In response to my complaint that POSIX invents one thing after another,
Chuck finishes his example of job control with this:

[e-mail] (Chuck Karish) writes:
> They chose invention as the lesser of two
> evils rather than standardize on something that was wrong.

Oh, I agree that the BSD job control model was wrong. I agree that
standardizing on a model with many huge flaws is stupid. By what stretch
of the imagination does this mean that standardizing on another model,
which not only has its own flaws but is compatible with nothing and
ridiculously complex, is any less stupid?

Your unstated assumption is that POSIX had to settle on *something*.
That's crazy. You don't go making standards this way. It is far, far
better to leave something completely unstandardized than to invent a
standard out of thin air.

Readers of comp.unix.wizards will have seen my new, extremely simple job
control model, inspired by a comment from Chris Torek. The model solves
all the problems that POSIX invented sessions to solve. It doesn't need
cttys or sessions. The programming interface consists of exactly three
function calls for manipulating process groups, yet it's enough to
implement a job-control shell. It doesn't interfere with BSD or POSIX
job control, so vendors can implement it safely.

Five people responded to that article. Three liked the model. One asked
how he could do certain operations; there were solutions in each case,
but he did convince me that it would probably be easier if one of the
calls were extended or a new call were available.

The last observed acidly that I'd never get NIST to change its mind
about a FIPS. Job control will never change again.

She was right. I like to think that if POSIX hadn't tried to standardize
job control, some vendors would have implemented my model, some programs
would have been written to use it, and eventually the sheer simplicity
of the interface would win most vendors and programmers over within five
or ten years. But POSIX did standardize job control. They took BSD job
control, mangled it, patched it so that the flaws were well concealed,
and made it into a standard that won't change in the foreseeable future.
Even worse, although they sensibly decided to make job control a mere
option, they made the patches mandatory. NIST drove the last nail when
it required the option as well.

I doubt that anything will change now. Vendors climb the POSIX peak and
think their users will be happy. They don't want to experiment---who can
improve on a standard? I can rewrite job control programs to use my
model, but without a platform I won't be able to convince anyone else to
follow my lead. Even Berkeley---once the home of UNIX innovation---cares
more about POSIX compliance than about trying to make life simpler for
programmers.

And you, Chuck, tell me that this is how it should be.

> To elaborate on the security and efficiency issues, I fail to
> see that either getconf or /inst/bin has any impact on the
> administrator's ability to maintain reasonable system security.

As others have pointed out, it is rather difficult to introduce getconf
into a system so that it actually increases security. You have to change
system() so that it always uses sh. You have to make getconf---or at
least the path part of it---a shell builtin. Programs which want to use
this convention for a secure PATH then have to spawn an extra process.

In contrast, to introduce /inst/bin into a system is easy. Just make the
directory and add the links. Programs which want to use this convention
for a secure PATH can simply call /inst/bin/tee and so on. Even better,
if you do want to go to all the effort of recompiling programs and
changing libraries, you can change the default login path to /inst/bin,
and all your old programs will use the path automatically. On some
systems you don't even have to recompile---you can just add a line to
/etc/cshrc and /etc/profile.

> As others have pointed out, the efficiency of using /inst/bin
> depends on the implementation.

Ah, but at least it's getting faster, as more and more vendors adopt
symlinks. For comparison, the efficiency of getconf doesn't really
depend on the implementation. It's slow everywhere.

> I consider it to be a poor
> candidate for standardization.

Oh, I do too. I consider every solution to this problem to be a poor
candidate for standardization, because (drum roll):

    The Market Hath Not Chosen A Solution.
    The Market Hath Hardly Even Considered The Problem.

Can you name a single vendor which has a solution to the problem of a
secure path for installed utilities? I'm listening.

> >In this particular case, existing programs can be used with /inst/bin
> >without even changing the source code. All you have to do is change the
> >default system PATH. Adding getconf to a program means that the program
> >will no longer work on the vast majority of systems. That's what I mean
> >by unportable.
> There's a simple fix that makes such scripts work:  install
> getconf.

But that requires work on the part of *everyone* who wants to use the
script! Surely you admit that this is not a good thing when it can be
avoided.

> The issue of script portability is something of a red herring,
> because it has never been possible to write really portable
> scripts.

Uh, say what? People *do* write scripts all the time which work on lots
of systems; Configure is a supreme example, but nearly every script is
portable to similar machines.

> getconf, sysconf(), pathconf() and fpathconf() exist to make it
> possible to allow programs to make full use of system
> capabilities without being re-compiled for differently-
> configured members of a binary-compatible family and without
> being crippled down to a lowest common denominator.

Here's your unstated assumption again: that the standard *has* to
provide some way to do anything that systems code might want to do.
Why? Why is this sort of invention better than letting the market come
to a consensus on each feature first?

---Dan

Volume-Number: Volume 24, Number 60