Patch info for syslog_danilche

Author Comments

Date: Thu, 23 Aug 2001 11:33:56 -0400 (EDT)
From: Victor Danilchenko <danilche@cs.umass.edu>
Subject: Stunnel logging facility?..

        Our installation relies on stunnel logging to authenticate
remote users -- by pairing up stunnel connection notice and IMAP or POP
login notice, we create a ticket for the user's IP. This was working
fine (kinda sorta -- SSL/POP wasn't working until version 3.19), until
recent upgrade, at which point stunnel started partially ignoring the
loigging spec.

We start it as follows:

/usr/local/sbin/stunnel -D mail.info -E /var/egd/randsock -d spop3 \
  -p /usr/local/ssl/certs/stunnel.pem -l /usr/local/etc/ipop3d spop3d

        The mail facility logs the following startup entries, and
nothing else (well, it also logs the terminating entries):

Aug 23 09:36:54 freya stunnel[26963]: Using 'spop3d' as tcpwrapper service name
Aug 23 09:36:54 freya stunnel[26963]: PRNG seeded successfully
Aug 23 09:36:54 freya stunnel[26963]: stunnel 3.20 on alpha-dec-osf4.0 PTHREAD

        BUT... the entries after that get logged in user.log (NOT
mail.log) are:

Aug 23 10:15:50 freya syslog: spop3d connected from 128.119.243.34:49221
Aug 23 10:17:46 freya syslog: spop3d connected from 128.119.243.34:49222

        Note that they are logged without the name or PID... I am sure
the other entries get logged thusly as well, but without the name they
are harder to track, and the "connected from" entry is what we are
interested in.

        I took a quick look at log.c, and it looks like it's *supposed*
to work -- and it obviously does, at first (the initial entries get
logged correctly); but somewhere along the line, the logging information
gets lost. Out of curiosity, I rebuilt stunnel with threading disabled;
the forking stunnel now logs into the mail.log as follows:


        Besides the error message at the end, the FORKing version does
log the connections correctly. It looks to me like the syslog facility
on Digital Unix 4.0d (and earlier, presumably) is not thread-safe --
only the parent thread seems to log the connections correctly.
Unfortunately, I don't have enough experience with C Pthreads to
implement the seemingly viable solution -- have the parent thread do
nothing but logging, have the children pass messaged to be logged to the
parent, and have a separate boss/listener thread to spawn the workers.

        For now, I am running the FORKing version of stunnel 3.20; the
severed SSL connection when wrapping POP that was plaguing stunnel 3.18,
does not reappear.


-------------------------------------------------------

Date: Thu, 23 Aug 2001 11:17:01 -0500
From: Brian Hatch <bri@stunnel.org>

Here's something you could do to test.  Edit sthreads.c and
find the create_client function.  Just before the 'return'
statements, add the following lines:

        log_close();
        log_open();

That'll close and re-open the log, which may do the trick.  I haven't
actually tried this, so I don't know if this is the best spot, or
even the only spot you'd need to try.
 
-------------------------------------------------------
    
Date: Tue, 28 Aug 2001 10:01:05 -0400 (EDT)
From: Victor Danilchenko <danilche@cs.umass.edu>

Actually, I took the idea of reopening the log, and applied it
one step further -- and it seems to work. Essentially, instead of
wrapping each client opening into a log reopen statements, I wrap each
log call into a log open/close pair; this approach seems to have worked,
in that the subthread syslog calls are now being processed and logged
correctly. Patch included. I am not sure what else such a drastic
approach might break, though, and it will certainly be a performance hit
under heavy load and high logging level.

This website makes patches available for use by the Internet community. However it does not endorse any of the patches contained herein. They could be work perfectly, or totally foul up everything. We don't know. Contact the authors if you have any questions. Use at your own risk.

The Stunnel software package does not contain any cryptography itself, however please remember that import and/or export of cryptographic software, code providing hooks to cryptographic algorithms, and discussion about cryptography is illegal in some countries. It is imperative for you to know your local laws governing cryptography. We're not liable for anything you do that violates your local laws.