Subject: Re: fork(2) vs. pthread_create() (fwd)
To: None <firstname.lastname@example.org>
From: Bill Squier <email@example.com>
Date: 06/11/2004 16:23:53
On Fri, Jun 11, 2004 at 12:51:47PM -0400, Nathan J. Williams wrote:
> Bill Studenmund <firstname.lastname@example.org> writes:
> >> We are able to output error messages...
> > From a library? No. You can't.
> Emmanuel is pointing out that we do, in fact, print messages to stderr
> in the various mutex error-detecting conditions that normally
> abort. They can be configured to just print the message and not abort,
> or to do neither.
> Perhaps we "shouldn't", but it's wrong to say that we "can't".
Although I'd like to weigh in on the "shouldn't" side, the problem lies in
answering the question "what should we do?". Christos and I examined that
question for libc years ago, and came to the conclusion that we were
basically screwed-- there's only so much information you can convey with
'errno', and that's assuming the function your talking about is even
defined to affect it.
You have similar restrictions in libpthread, unfortunately.
Applications that link against these libraries have to be aware that if
they're going to do anything with stderr, they better not do something like
connect it to "/etc/passwd".
> > The fact that libraries sometimes output to stderr is actually a security
> > issue. Consider a daemon that has hooked something other than stderr to fd
> > 2. If you can trigger the program to call a routine that outputs an error
> > (and/or you can trigger the conditions of the error), you can get
> > arbitrary data send down whatever's hooked to fd2.
Exactly, which means that applications just can't make such assumptions.
Part of the "API" of the library has to include the presumption that stderr
may have arbitrary text sent to it.
Bill Squier (email@example.com) http://www.netbsd.org
I know I don't deserve another chance, but this _is_ America,
and as an American, aren't I entitled to one? --Sideshow Bob.