using glibc built with ct-ng.

This is very strange, since LOG_KERN is (0<<3), in other words, it's zero. Thus, ORing LOG_KERN to anything is a NOP.

This is code from 1.4.1:


        openlog("kernel", 0, LOG_KERN);
...
                priority = LOG_INFO;
                for (i = 0; i < n; i++) {
                        if (lastc == '\0' && log_buffer[i] == '<') {
                                i++;
                                // kernel never ganerates multi-digit prios
                                //priority = 0;
                                //while (log_buffer[i] >= '0' && log_buffer[i] <= '9') {
                                //      priority = priority * 10 + (log_buffer[i] - '0');
                                //      i++;
                                //}
                                if (isdigit(log_buffer[i])) {
                                        priority = (log_buffer[i] - '0');
                                        i++;
                                }
                                if (log_buffer[i] == '>')
                                        i++;
                                start = &log_buffer[i];
                        }
                        if (log_buffer[i] == '\n') {
                                log_buffer[i] = '\0';   /* zero terminate this message */
                                syslog(priority, "%s", start);


As you see, it uses LOG_KERN in openlog() and does not use anything to override it in priority parameter in syslog().

And last, could you please re-test it with less ancient version of busybox?

At closer look, it is a real bug in uclibc. I fixed it in uclibc trunk and also hopefully it will be fixed in uclibc 0.9.30.2

The same bug is present in glibc (!). It is not obvious since "standard" klogd contains a reimplementation of openlog() and syslog() routines from libc (!!!).

glibc bug:

https://bugzilla.redhat.com/show_bug.cgi?id=547000

it is not a bug in glibc and neither in uclibc, although at first glance it really looks as if it were.

if you look at the man page of openlog:

  LOG_KERN       kernel messages (these can't be generated from user processes)

it is intended that it does not work as easy as openlog(... LOG_KERN).
I could not figure out why but the klogd deamon from the buildroot sysklogd package works correctly with exactly the same glibc. so there are ways how to do it.

http://sources.redhat.com/ml/libc-alpha/2000-03/msg00060.html

(In reply to comment #6)
> it is not a bug in glibc and neither in uclibc, although at first glance it
> really looks as if it were.
> 
> if you look at the man page of openlog:
> 
>   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>This is a load of bull" there. Voila, a LOG_KERN + LOG_EMERG message is logged! Run for your lives...

> it is intended that it does not work as easy as openlog(... LOG_KERN).

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 harder.

> I could not figure out why but the klogd deamon from the buildroot sysklogd
> package works correctly with exactly the same glibc. so there are ways how to
> do it.

Because it has its own (old and a bit broken) implementation of openlog() and syslog().

(In reply to comment #8)
> 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
> harder.
I agree with you and I am not at all content with the implementation since it had cost me quite some time to get a kernel log filter running.
But I do not think that a bug report for glibc or uclibc will get us anywhere. 
The disscussion about the topic is not new I think. So I believe the decision to leave the behavior of openlog this way is settled.

I see it this way:
* uclibc is fixed,
* glibc bug is filed, even though I expect glibc people to switch into their customary "we are the bosses, you are the idiot, we know better" mode and declare it "not a bug, it's a feature"


I hesitate to reimplement syslog() function just for klogd...

in the mail discussion in the link I provided, there is also a second reason why the "bug" was decided to not be fixed. which is that some applications provide 0 as a valid default value which translates to LOG_USER.

changing the meaning of value 0 makes some applications log as kernel. 
So I guess glibc folks are fine to not let this happen.

> which is that some applications
provide 0 as a valid default value which translates to LOG_USER.

"man openlog" actually does not say that 0 is a valid value.
It only mentions "default" in this part:

       LOG_USER (default)
              generic user-level messages

which might be interpreted as "if you don't call openlog() before you use syslog(), LOG_USER is used as facility by default".

I searched for applications which use literal 0 as facility in openlog() call using Google code search, and I found literally one or two such programs in entire open source world. Vast majority properly uses LOG_foo constants.

While browsing about this bug I found out that a recent fix was implemented in glibc, as tracked by this discussion https://sourceware.org/bugzilla/show_bug.cgi?id=3604, and the next release maybe will include the related commit (https://sourceware.org/git/?p=glibc.git;a=commit;h=f2913118cdbe72e1e6d89273eddabdf35e9d6b73).
I included this patch myself and solved this within our Busybox utilization.

I realize this is a very old report but if someone also finds this issue, I hope that information helps out the discussion, and maybe closes this issue.

Took only 12 years for glibc to acknowledge they are wrong. Power corrupts.