Bug 547000

Summary: openlog(xx, 0, LOG_KERN) acts like openlog(xx, 0, LOG_USER)
Product: [Fedora] Fedora Reporter: Denys Vlasenko <dvlasenk>
Component: man-pagesAssignee: Ivana Varekova <varekova>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: jakub, schwab, varekova
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-15 07:39:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Denys Vlasenko 2009-12-13 04:30:07 UTC
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.

Comment 1 Denys Vlasenko 2009-12-14 12:39:15 UTC
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)" ?

Comment 2 Ivana Varekova 2009-12-18 11:31:15 UTC
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.

Comment 3 Ivana Varekova 2010-01-27 14:19:03 UTC
Andreas, could you please clarify what is the right behaviour and describe describe here the man-page change fix?

Comment 4 Ivana Varekova 2010-02-15 07:39:13 UTC
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).