Red Hat Bugzilla – Bug 547000
openlog(xx, 0, LOG_KERN) acts like openlog(xx, 0, LOG_USER)
Last modified: 2010-02-15 02:39:13 EST
This test program LOG_KERN.c: #include <syslog.h> int main(int argc, char **argv) { openlog("log_kern_test", 0, LOG_KERN); syslog(LOG_NOTICE, "test test test"); return 0; } results in "test test test" being logged with LOG_USER facility. strace shows: send(3, "<13>Dec 13 05:21:37 log_kern_tes"..., 49, MSG_NOSIGNAL) = 49 "<13>" is wrong, it should have "<5>" there. It happens because LOG_KERN is zero, and zero is used as "use default facility" by openlog_internal code: if (logfac != 0 && (logfac &~ LOG_FACMASK) == 0) LogFacility = logfac; This is used in __vsyslog_chk to use default facility: /* Get connected, output the message to the local logger. */ if (!connected) openlog_internal(LogTag, LogStat | LOG_NDELAY, 0); One possible fix is to drop "logfac != 0" check in 1st code fragment and use explicit LOG_USER instead of 0 in that call to openlog_internal.
Man page of openlog states: LOG_KERN kernel messages (these can't be generated from user processes) ...but there is no way to prevent it. Any process can open a socket to "/dev/log" and write a string "<0>Voila, a LOG_KERN + LOG_EMERG message!" there. Making openlog(xx, xx, LOG_KERN) intentionally broken does not help one iota in preventing this sort of "attack". It only makes writing legitimate code (e.g. klogd) harder. As far as I see, "man openlog" does not state that "facility" argument in openlog() call can be set to 0, or that LOG_KERN is prohibited. As I see it, programmers should not pass 0 there since such usage is not documented, they should pass LOG_USER if that's the facility they want. To forestall future improper usage, it makes sense to amend "(default)" at LOG_USER in manpage. Now it looks like this: LOG_USER (default) generic user-level messages How about "(default if openlog was not called explicitly)" ?
Hello, please could you clarify, why this is not glibc bug and this is expected behaviour and attach here the patch for man-pages which will fix the issue.
Andreas, could you please clarify what is the right behaviour and describe describe here the man-page change fix?
Hello, there was no replay whether the behavior is wanted and man-page should be fixed or not. SZo I'm closing the bug (insufficient_data).