Re: [exim-dev] Why does tls_dropprivs_validate_require_ciphe…

Góra strony
Delete this message
Reply to this message
Autor: Michael Haardt
Data:  
Dla: pdp
CC: exim-dev, jgh
Temat: Re: [exim-dev] Why does tls_dropprivs_validate_require_cipher() call fflush(NULL)?
> Actually, I mis-spoke: it was because of the fork(). C code I write
> always does a fflush(NULL) before a fork(), to ensure that content
> doesn't get doubled. I think I picked this habit up from a W. Richard
> Stevens book (not sure, it's been too many years). It's that, more than
> anything about any particular I/O stream.
>
> Looking briefly at the codepaths, it looks like some logs going to
> stderr may be in buffers at the point of the fork. I don't have time to
> investigate further at this point.


That's what I was afraid of: It is not known what's open and inherited
at a security boundary transition, so everything is flushed.

> Seriously, much as I'd be happy to see Sun4 compatibility restored[*], if
> ANSI C stdio is to be avoided at this level, we may be in the territory
> of "patches needed to build".


fflush(NULL) usually says "I got lost and try to cover that by saying
I write robust code". There are ways to let this code work unmodified
even on SunOS 4, like macros using wrapper functions, but to me it looks
like a particularly bad place to get lost.

As for logging, I see log_close_all() and prefer to see something like
log_flush_all() being called, so it is easy to know what's going on there.
I would have expected exim_exit() to be used in the child and having
that call log_close_all(), instead fflush(NULL) and _exit() is used.
If that is to avoid the side effects of exim_exit(), the child should
rather free resources that must not be used first.

Given all that, I'm far from suggesting to change anything there without
understanding it really. :-/

Michael