System call error handling

[Dan Bernstein]

In article <27AEF248.6C25 at tct.uucp> chip at tct.uucp (Chip Salzenberg) writes:
> I would suggest, then, that pty should have code like this:
  [ error reporting ]

But the process in question almost certainly doesn't have stderr! This
isn't just an artifact of some arbitrary design decision; if, for
example, stderr is pointing to the user's original terminal, then under
at least Clare's interpretation of POSIX ``security'' the process
shouldn't even be able to keep access to it. Furthermore, the master
process may become disconnected (as per Steve Bellovin's session manager
design) and reattach to a different process; what is it supposed to do
with stderr in this case? There are some solutions---like shuttling new
stderrs back and forth---but they introduce more unreliability than
there is in the original code you're complaining about.

> Yes, it's tedious.  But to omit tests for these possibilities when
> there is something to be done is poor programming practice, with no
> ifs, ands or buts.  (Printing an error message _is_ doing something.)

I'd probably agree with you if printing an error message were feasible
in that section of code. But it's not.

Again, could you please make the effort to read the code in context
before you criticize it?

> >Don't you read code before you criticize it?
> Context is always important.  But there are some things that you just
> _don't_ mess around with, and user ids are at the top of the list.

If anyone, anywhere, ever sees pty break security, I'll repent.

> >Chip, be reasonable. You can't demand of system programs that they check
> >for external system consistency at every step.
> Oh, really?  Read Deliver 2.0 PL12 and make that statement again.

Chip, be reasonable. You can't demand of system programs that they check
for external system consistency at every step.

---Dan