Trojan Horses

[Boyd Roberts]

In article <19547:Oct1818:25:2690 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>This is a failure of NFS, not a reason to check close(). (Well, close()
>should be restarted on EINTR, but that's a side issue.) It's not right
>to give the programmer the burden of working around NFS's bugs. Same for
>AFS.
>

Always, always, always check the return values of system calls.
It costs nothing and can save you from potential embarassment
at some laster time.  It something has an error return you
_must_ check for it.

It's not a matter of `working around ... bugs'.  It's all about
good programming style.  It's incredibly useful to have good
diagnostics for even the worst end case.

Take NFS for example.  When it breaks I'd like to know which system
call failed and why.  That way you _know_ what's going on, or at
least you have a handle on it.  There's nothing worse than silence
when something goes weird on you.

One horror story springs to mind with setuid(2) and setgid(2).
This (large) piece of code started off running as root and
then went setgid() followed by setuid() to become right `user'.

Did it check what setuid() and setgid() returned?  How many of
you check what those two return?  Anyone?  Anyway, the setuid()
and setgid() both FAILED which caused the software to fail in
strange ways.

On a `real' UNIX machine this wouldn't be a problem.  But, welcome
to SCO and their C2 security nightmare.  Because this stuff was invoked
by init it had no `login user id'.  The documentation for set[ug]id(2)
states that both calls would fail if the `login user id' was not set.  This
thing can be set once and _only once_.  It's done by login(1) and su(1).

Goodbye UNIX semantics -- hello Mom*.

Anyway, if the programmer of this piece of code (not me) had checked
what set[gu]id() returned it would have been far easier to track down.
At least, I would have had a pointer to the real problem rather than
having to trek through a large software package with only a vague idea
of what the problem was.


Boyd Roberts			boyd at necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''

* With apologies to Scatterbrain.