From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id D0E8E22316 for ; Thu, 13 Jun 2024 17:22:43 +0200 (CEST) Received: (qmail 16062 invoked by uid 550); 13 Jun 2024 15:22:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 16024 invoked from network); 13 Jun 2024 15:22:38 -0000 Date: Thu, 13 Jun 2024 15:20:11 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com cc: erny hombre In-Reply-To: <20240613134607.GW10433@brightrain.aerifal.cx> Message-ID: References: <20240613134607.GW10433@brightrain.aerifal.cx> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [musl] possible bug in syslog Rich Felker dixit: >If I follow correctly, the bug here is that the nonstandard >functionality of passing a facility to syslog() At least on BSD, it is expected to work: | The facility parameter encodes a default facility to be assigned to all | messages that do not have an explicit facility encoded: Although it also has=E2=80=A6 | #define LOG_MAKEPRI(fac, pri) (((fac) << 3) | (pri)) =E2=80=A6 the uses are=E2=80=A6 | bin/date/date.c: syslog(LOG_AUTH | LOG_NOTICE, "date set by %s", pc); =E2=80=A6 and=E2=80=A6 | #define LOG_USER (1<<3) /* random user-level messages */ =E2=80=A6 so I guess it suffers from the same bug. $ ./a.out exampleprog[11414]: LOG_DAEMON | LOG_NOTICE exampleprog[11414]: LOG_LOCAL7 | LOG_NOTICE exampleprog[11414]: LOG_MAKEPRI(LOG_DAEMON, LOG_NOTICE) exampleprog[11414]: syslog: unknown facility/priority: 5c5 exampleprog[11414]: LOG_MAKEPRI(LOG_LOCAL7, LOG_NOTICE) The only users of LOG_MAKEPRI in the entire tree are Sys::Syslog::Syslog (Perl XS) though and=E2=80=A6 sys/sys/syslog.h:#define INTERNAL_MARK LOG_MAKEPRI(LOG_NFACILITIES= , 0) sys/sys/syslog.h: { "mark", INTERNAL_MARK }, /* INTERNAL= */ =E2=80=A6 so this is probably fixed more easily than when having to keep ABI. LOG_FAC has one more user than Perl, but=E2=80=A6 /* * Don't allow users to log kernel messages. * NOTE: since LOG_KERN =3D=3D 0 this will also match * messages with no facility specified. */ if (LOG_FAC(pri) =3D=3D LOG_KERN) pri =3D LOG_USER | LOG_PRI(pri); =E2=80=A6 this is also very nicely written to not hit this bug. LOG_FACMASK must of course match the next power-of-two-minus-one for (LOG_NFACILITIES << 3)=E2=80=A6 so, yes, 0xF8 is correct for BSD as wel= l. What do you think about=E2=80=A6 #define LOG_MAKEPRI(fac,pri) (((fac) & LOG_FACMASK) | ((pri) & LOG_PRIMA= SK)) =E2=80=A6 however? With the three changes applied, the test program is happy: $ ./a.out exampleprog[6837]: LOG_DAEMON | LOG_NOTICE exampleprog[6837]: LOG_LOCAL7 | LOG_NOTICE exampleprog[6837]: LOG_MAKEPRI(LOG_DAEMON, LOG_NOTICE) exampleprog[6837]: LOG_MAKEPRI(LOG_LOCAL7, LOG_NOTICE) >Another option would be to leave the macro definitions alone (i.e. >preserve existing ABI) and make syslog accept the packing we >inadvertently defined with the 3 empty bits between priority and >facility. This would not bring the MAKEPRI and the =E2=80=9Cor=E2=80=9D method into congruence, and, assuming you actually test that the three bits are 0 and at least one higher isn=E2=80=99t, it would still mean LOG_UUCP/LOG_USER, LOG_LOCAL0/LOG_MAIL, LOG_NFACILITIES/LOG_DAEMON (strictly speaking) confusion. >I'm not sure what we should do since this functionality has never >worked right, and since it's fairly obscure and nonstandard. Let's >wait a bit and see if anyone else has opinions on which way to fix it. Did musl crib the logging framework from a BSD? In that case I=E2=80=99d go with the suggested fix, as LOG_MAKEPRI probably is more rarely used. I was just going to do a codesearch on Debian when I saw the new reply (not in the thread) that=E2=80=A6 >Here (https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functio= ns/syslog.html) >I found this: Values of the priority argument are formed by OR'ing >together a severity-level value and an optional facility value. =E2=80=A6 indicates that, yes, =E2=80=9Cor=E2=80=9Ding must be possible. I=E2=80=99ll commit the fix to MirBSD now. Thanks erny for raising. bye, //mirabilos --=20 > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. =09-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc