earle@smeagol.UUCP (Greg Earle) (12/21/85)
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@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 <=