Solar Designer wrote:
[]
> I agree with Michael in that the application's logging function should
> accept an already-formatted string, as it would need to do some magic
> to combine two va_list's otherwise. Unfortunately, this requires that
> libpam either imposes a limit on the log line length, or allocates a
> piece of memory dynamically. The latter can be done with vasprintf()
> (non-portable) or a loop around vsnprintf() (probably acceptable).
All at once seemed a bit ugly :(
Ok, at least should have something like:
char defbuf[256]; <== some not very large but still enouth
for most cases size
char *buf = defbuf;
int size = sizeof(defbuf);
while (snprintf(buf, size, ...) cant fit in size) {
size *= 2;
buf = (buf == defbuf) ? malloc(size) : realloc(buf, size);
}
Far more good will be to have
char nfmt[strlen(format) + sizeof("%s: %s ")]; (maybe alloca'd)
strcpy(nfmt, "%s: %s ");
strcat(nfmt, format);
va_prepend(args, module); \ where va_prepend() lives?! :)
va_prepend(args, service); /
callback(priority, module, service, nfmt, args);
but that's impossible now... :(
Maybe something similar exists?
[]
> What about logging priorities? It should be possible to pass the
> usual syslog priority level constants via pam_log(), but they may not
> fit non-syslog logging types very well. Also, is it the application
> which decides the priority level for log entries from PAM modules, or
> should the modules decide themselves (such as to support different
> levels for different kinds of events). I think that it wouldn't hurt
> to pass a priority level, but the application-provided logging
> function should be free to ignore that.
Not so many applications will require custom logging. And it is not
so hard to implement "conversion" from syslog priorities to application
ones if needed.
> I suggest that we define things like this (all in libpam):
>
[]
> int pam_log(int priority, char *format, ...)
> {
> char *message;
> [...]
> [va_start]
> [vasprintf/vsnprintf]
> retval = pam_log_callback(service, module, priority, message);
> [va_end]
> [...]
> return retval;
> }
int pam_log(int priority, char *format, ...)
{
[va_start]
retval = pam_vlog(priority, format, va_list)
[va_end]
return retval;
}
int pam_vlog(int priority, char *format, va_list args)
{
char *message;
[...]
[vasprintf/vsnprintf]
retval = pam_log_callback(service, module, priority, message);
[va_end]
[...]
return retval;
}
> int pam_log_default(char *service, char *module, int priority, char *message)
> {
> openlog(service, LOG_PID, LOG_AUTH);
> syslog(priority, "%s: %s", module, message);
> closelog();
>
> return 0;
> }
int pam_log_default(char *service, char *module, int priority, char *message)
{
char *locale = getlocale();
setlocale(LC_ALL, "C");
openlog(service, LOG_PID, LOG_AUTH);
syslog(priority, "%s: %s", module, message);
closelog();
setlocale(locale);
return 0;
}
sigh! (This is only prototype, I don't have manuals about
locales here).
I'm enouth with entries with different charsets in system logs!
Russian has at least 4 commonly-used encodings, and each user
free to set his preffered one. As a result, at least month
namess in log entries are completely unreadable. :(((
I have this when debugging my new pam_unix -- I started login
from command line with my usual LANG settings.
Regards,
Michael.
