RE: [Exim] Libc_r

Pàgina inicial
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
A: Juha Saarinen
CC: Exim-Users@Exim. Org
Assumpte: RE: [Exim] Libc_r
On Tue, 1 May 2001, Juha Saarinen wrote:

> /usr/lib/libc_r.so: WARNING! setkey(3) not present in the system!


There is no reference to the text "setkey" in the Exim source.

> /usr/lib/libc_r.so: warning: this program uses gets(), which is unsafe.


Exim uses fgets() in several places, but not gets(). Note that fgets()
has a count in it, whereas gets() does not - which is presumably why the
latter is deemed unsafe. I've never used gets(), for this reason.

> /usr/lib/libc_r.so: warning: mktemp() possibly used unsafely; consider using
> mkstemp()
> /usr/lib/libc_r.so: WARNING! des_setkey(3) not present in the system!
> /usr/lib/libc_r.so: WARNING! encrypt(3) not present in the system!


The Exim source makes no reference to mktemp(), des_setkey() or
encrypt().

> /usr/lib/libc_r.so: warning: tmpnam() possibly used unsafely; consider using
> mkstemp()


This has been pointed out a while ago; the next release of Exim makes
use of the standard function tmpfile() instead.

> /usr/lib/libc_r.so: warning: this program uses f_prealloc(), which is
> stupid.


There is no reference to f_prealloc in the Exim source.

> /usr/lib/libc_r.so: WARNING! des_cipher(3) not present in the system!


There is no reference to des_cipher in the Exim source.

> /usr/lib/libc_r.so: warning: tempnam() possibly used unsafely; consider
> using mkstemp()


There is no reference to tempnam, though it does use tmpnam (see above).

I infer that all these functions that are being complained about, with
the exception of tmpnam(), are actually called from some of the
libraries that are being linked with Exim.

> Same result as with the ports version of Exim:


Oh dear.

> In queue.c, I put it on line 582 and 584:
>
> if (!recurse)
>   {
>   if (smtp_etrn_serialize && deliver_selectstring != NULL)
>     transport_end_serialized("etrn-runs", deliver_selectstring);
>   log_write(log_queue_run_level, LOG_MAIN, "End queue run: %s", log_detail);
>   debug_printf("Really the end of the queue run...\n");
>   }
>  debug_printf("Or does it end here?\n");
> }

>
> Result:


> LOG: 0 MAIN
> End queue run: pid=4978
> Really the end of the queue run...
> Or does it end here?
> Segmentation fault


I'm baffled. That final print line is at the end of the function
queue_run(), which is called from one of two places:

1. If you have not defined an Exim uid, it's called directly from a
process forked by the daemon. The very next statement is
_exit(EXIT_SUCCESS).

2. If you have defined an Exim uid, the daemon re-exec's Exim, and
queue_run() is called from exim.c and again, there is a call to exit()
immediately afterwards.

Hmm. Maybe the crash is happening back in the daemon process, and is
nothing to do with the queue run. Maybe something else is happening that
causes it to crash? The daemon has been very stable. I suppose you could
put more debug_printf statements in the daemon. For example, just before
line 1010

if (daemon_sigalrm_seen)

which is the start of its never-ending loop. Another place is 1235

while ((pid = waitpid(-1, &status, WNOHANG)) > 0)

where it is checking for the termination of sub-processes (e.g. the
queue runner).

Sorry I'm not being very helpful. If you want to give me an account on
your box and access to your source tree to let me try to sort it out
from there, I'll do that. (The problem with that is, though, that Exim
has to be setuid root in order to start the daemon.)

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.