Using 'syslog(3)' in login.c

[Greg Earle]

I am attempting to remedy what I think is an oversight in the implementation
of /bin/login on a Sun.  When one does an 'su(1)', the result, either good
or bad, is logged to the console (if it can be opened for writing) and to
the syslog file /usr/spool/log/syslog, if an openlog(3) attempt succeeds.
Login(1) will log all good/bad attempts to login to a dialin line, if you
have changed the dialin line from /dev/whatever to /dev/ttyd[0-9].  The
problem is that login ONLY logs to the console; it makes no effort to make a
log entry for any dialup attempts.  On a Sun, this is intolerable, because
it puts the S.A. in the awkward position of having to be "first-one-in" in
the A.M. in order to see if there were any hack attempts on his dialup at
night; if anyone else logs in, the record of dialup activity is obliterated.
I was under the assumption that this was probably a holdover from the VAX
BSD days, when most VAXen have LA-100/120/36's as HARDCOPY consoles, and
this is not a problem for them (unless the bugger breaks in to the computing
center and rips the paper out of the console).  Not so for the Sun.  So...

I basically took the cue from su.c, and changed the function logerr in
login.c so that if the log file was opened via a successful openlog(3) call,
it would write in the dialup info, just like su does for itself.
Unfortunately, then the fun began.  I am now finding that the first attempt
will be logged ok (DIALUP or BADDIALUP), but if there is a BADDIALUP (with
a subsequent reissuance of the 'login:' prompt), every attempt bad or good
from then on (that is, until a good login seems to 'reset' things) will
NOT get logged, and the unfriendly message

        syslog: sendto: Destination address required

appears on the dial-in terminal.  I was under the impression that syslog
didn't need to be run as a daemon; that it would be called when it was
needed (i.e. when a syslog(3) call gets executed).  So my question is:
Is this message generated because the syslog request comes too fast behind
the last one to be processed correctly (as in, nobody home to receive the
Datagram)?  Could it possibly be a bad parameter to the syslog call, that
works ok the first time, but a second invocation (before exiting login) or
third, etc. will have incorrect information in it?  I would have thought
that the syslog(3) parameters have got nothingto do with the internal
sending of the datagram ...

        Greg Earle
        JPL Spacecraft Data Systems Group
        ..!sdcrdcf!smeagol!earle                        (UUCP)
        ia-sun2!smeagol!earle at cit-vax.arpa      (ARPA)

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

=> Know Your Culture <=
"Spleen and Ideal", LP by Dead Can Dance (4AD records, import)
                        ... for those not Stuck In The Seventies
                        ("Hey, maaaannnn, Sabbaff is fuggin radddd, dude")
=> # 4 in a series <=