From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by sourceware.org (Postfix) with ESMTPS id DF2D83857C6F for ; Wed, 31 Mar 2021 19:27:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DF2D83857C6F Received: by mail-qk1-x72d.google.com with SMTP id c4so20562673qkg.3 for ; Wed, 31 Mar 2021 12:27:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UW6KoF3F6UHqu0nYEnHjFRtgmCcTYtvNIujbBS5RnfM=; b=YGUZ7CPMCH3rIlVawYTY7pRW2gJmicJZZyq62BbdAEz9VSMBXB8H4AKsaJgGnn2tCA rbcO8rzOwjeNUcz3BJJwz1IhHsxefCvEBOm0NZH0HvZLZZGKu28/jAIr5ORMwts2oo4O V8zTeBv78ngoEyGsMsFrXOLe6uvwJG2BoRIwLBuvFxUM9x9urjfFnxvDb59L49BA127P VDb8Jj7MUjWhWzwTlja/y2ZYWS3CJRczaeij10hulowodRbH20I8tsZpC716imEEw9Zg 4m+aUKjJOkC7/y0IFsgv9v5X1KbVUko+lGUthOlcpjjEH5CPKSGv7/rzNbhB4Rsf2hbj TUqg== X-Gm-Message-State: AOAM531dXfZoixfp5Xlk9YqV3fMhG16Q01nBCWPL+8cB0oRzNugKv0zU yJpE01ekRg2cvENMGFnOgGfWGA== X-Google-Smtp-Source: ABdhPJwaoSeLhmB10EjK2K1xIst+ktrR2q44d55AsuBaPXXWlKdm3+UGI+d8NxbkH4ZDIG+SipEmoA== X-Received: by 2002:ae9:e50c:: with SMTP id w12mr4730555qkf.13.1617218877345; Wed, 31 Mar 2021 12:27:57 -0700 (PDT) Received: from ?IPv6:2804:14c:485:832:932f:4cf0:cfa7:3d8c? ([2804:14c:485:832:932f:4cf0:cfa7:3d8c]) by smtp.gmail.com with ESMTPSA id a19sm2170922qkl.126.2021.03.31.12.27.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Mar 2021 12:27:57 -0700 (PDT) Subject: syslog and LOG_KERN - Re: [PATCH] Bug 3604: fix calls to openlog() with LOG_KERN facility To: Dan Raymond , libc-alpha@sourceware.org, Rich Felker , libc-coord@lists.openwall.com References: <1395b5b8-0fc7-ae01-c8e1-5e13f3a4394c@foxvalley.net> From: Adhemerval Zanella Message-ID: <86d18b12-c12b-9837-de7a-9dcb377ed6c4@linaro.org> Date: Wed, 31 Mar 2021 16:27:54 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <1395b5b8-0fc7-ae01-c8e1-5e13f3a4394c@foxvalley.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 19:27:59 -0000 On 27/03/2021 17:07, Dan Raymond wrote: > From 93683928886a563a4740e2b42b53752a4a7d431f Mon Sep 17 00:00:00 2001 > From: Dan Raymond > Date: Sat, 27 Mar 2021 13:51:16 -0600 > Subject: [PATCH] Bug 3604: fix calls to openlog() with LOG_KERN facility > Not allowing LOG_KERN by any user process seems to be de facto behavior on all systems I am aware of: * FreeBSD and MUSL explicit set to previous log facility (they check if the priority against a mask and since on both LOG_KERN is 0 is set to the previous/default value). * Solaris 11.4 man page explicit says: LOG_KERN Messages generated by the kernel. These cannot be gener- ated by any user processes. * AIX 7.2 is similar, but it seems to provide a special symbol for that (which seems to not have a man page): LOG_KERN Logs messages generated by the kernel. Kernel processes should use the bsdlog routine to generate syslog messages. The syntax of bsdlog is identical to syslog. The bsdlog messages can only be created by kernel processes and must be of LOG_KERN priority. The syslog subroutine cannot log LOG_KERN facility messages. Instead it will log LOG_USER facility messages. So before to make glibc an outlier here to fix a very specific issue, I would like to check with other implementation the possible security implication and whether it make sense to change it. Reference: https://sourceware.org/bugzilla/show_bug.cgi?id=3604 > --- >  misc/syslog.c | 6 +++--- >  1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/misc/syslog.c b/misc/syslog.c > index 2cc63ef287..bb30cd963a 100644 > --- a/misc/syslog.c > +++ b/misc/syslog.c > @@ -285,7 +285,7 @@ __vsyslog_internal(int pri, const char *fmt, va_list ap, > >      /* Get connected, output the message to the local logger. */ >      if (!connected) > -        openlog_internal(LogTag, LogStat | LOG_NDELAY, 0); > +        openlog_internal(NULL, LogStat | LOG_NDELAY, LogFacility); > >      /* If we have a SOCK_STREAM connection, also send ASCII NUL as >         a record terminator.  */ > @@ -299,7 +299,7 @@ __vsyslog_internal(int pri, const char *fmt, va_list ap, >          /* Try to reopen the syslog connection.  Maybe it went >             down.  */ >          closelog_internal (); > -        openlog_internal(LogTag, LogStat | LOG_NDELAY, 0); > +        openlog_internal(NULL, LogStat | LOG_NDELAY, LogFacility); >            } > >          if (!connected || __send(LogFile, buf, bufsize, send_flags) < 0) > @@ -343,7 +343,7 @@ openlog_internal(const char *ident, int logstat, int logfac) >      if (ident != NULL) >          LogTag = ident; >      LogStat = logstat; > -    if (logfac != 0 && (logfac &~ LOG_FACMASK) == 0) > +    if ((logfac &~ LOG_FACMASK) == 0) >          LogFacility = logfac; > >      int retry = 0;