log entries format(s)

2002-08-06T14:33:50Z

Priority: Low
Impact: Cosmetics

The following log() calls seems to be strange due to
message formmating or parameters passing, ...

FILE:LINE: source code
- missing space between %s and text may caused the
log record hard to read
radiusd.c:847: log(L_ERR, "%saccounting
process died - exit.", me);
radiusd.c:850: log(L_ERR, "%sfailed in
select() - exit.", me);
radiusd.c:853: log(L_INFO, "%sexit.", me);
radiusd.c:856: log(L_ERR, "%sexit on signal
(%d)", me, sig);

- some of formats is missing
auth.c:850: log(L_AUTH,
"Login incorrect: [%s] (%s) "
"(external check failed)",
namepair->strvalue,
auth_name(authreq, 1));

- unification of messages with same cause
There are few groups of messages which has various
message texts (only three examples are given)
1. Out of memory (no memory, Out of memory!,...)
2. Can't fork (Accounting: fork: %s, Fork failed ...)
3. Can't open file (cannot open ..., Couldn't open %s
for ...)
The unified message may contain name of the
subsystem which was affected.

Regards David

Buffer overflow

2002-08-06T13:47:22Z

Hi,
I've found bug mentioned above in file: cache.c

The following fragment of code is located in affected file
on two places.

if((len+1) > MAXUSERNAME) {
log(L_ERR, "HASH: Username too long in line: %s",
buffer);
}
strncpy(username, buffer, len); /* BUFFER OVERFLOW
HERE */
username[len] = '\0';

The proposed change is placing
len = MAXUSERNAME - 1;
to the enbraced block such as:
if((len+1) > MAXUSERNAME) {
log(L_ERR, "HASH: Username too long in line: %s",
buffer);
len = MAXUSERNAME - 1;
}

The less important issue is that the both messages
aren't same but similar (they have different number of
spaces). This inconsistency may caused problems
during parsing of log file.

Regards David.

Recent changes to bugs

log entries format(s)

Buffer overflow