Bug#390743: logwatch: unmatched postfix-mysql and libnss-mysql log messages
Willi Mann wrote: This says LOG_ERR, and I don't think we should kill error messages. However, it would make sense to summarise it, to avoid differnent process numbers to make the list of Unmatched Entries longer. Superfluous non-error messages reported against libnss-mysql as bug #390972: libnss-mysql: please don't report errors reading nss-mysql-root.conf for non-root users Andreas PS: I just tried libnss-mysql-bg - this does not throw superfluous error messages, so I will probably switch permanently and won't see the error any more. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390743: logwatch: unmatched postfix-mysql and libnss-mysql log messages
Andreas Beckmann schrieb: Package: logwatch Version: 7.3.1-2 Severity: normal Hi, postfix-mysql and lib-nss-mysql spit out a few messages that are not recognized in the secure log script. I added the following lines to scripts/services/secure in order to ignore these messages: or ( $ThisLine =~ /^postfix\/smtpd\[\d+\]: sql auxprop plugin using mysql engine/ ) or ( $ThisLine =~ /^postfix\/smtpd\[\d+\]: sql plugin .*/ ) or ( $ThisLine =~ /^postfix\/smtpd\[\d+\]: (begin|commit) transaction/ ) Will postfix/smtpd report anything useful to the secure logfile? If not, we should ignore it completely. There are quite a few 'sql plugin .*' debug messages and I was to lazy to list them all separately :-) or ( $ThisLine =~ /^nss-mysql\[\d+\]: _nss_mysql_getspnam_r conf file parsing failed/ ) That is correct behaviour of libnss-mysql and caused by a non-root process executing the equivalent of 'getent shadow'. Since this needs to read a password column from the database the configuration file containing the database password is readable by root only. (There is a separate world readable configuration for passwd/group, but the database password contained there should not allow access to the password column). Why is this reported? Is it not possible to configure nss-mysql to not even try to parse that conffile? It looks to me as if this log message reports a (minor) misconfiguration. If it is possible to avoid that message, then it's OK to report it as Unmatched Entry (this is the statement from Bjorn L. from upstream) Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390743: logwatch: unmatched postfix-mysql and libnss-mysql log messages
Willi Mann wrote: Will postfix/smtpd report anything useful to the secure logfile? If not, we should ignore it completely. postfix/smtpd messages from auth.log (user/domain info obscured and ran though sort | uniq -c | sort -n): 113 sql plugin create statement from cmusaslsecretCRAM-MD5 user example.com 115 sql plugin create statement from userPassword user example.com 126 begin transaction 126 commit transaction 229 sql plugin Parse the username [EMAIL PROTECTED] 230 sql plugin doing query select password from mail_users where username='[EMAIL PROTECTED]'; 261 sql plugin try and connect to a host 261 sql plugin trying to open db 'dbname' on host '127.0.0.1' 2170 sql auxprop plugin using mysql engine There seems to be no useful information from postfix/smtpd in auth.log. or ( $ThisLine =~ /^nss-mysql\[\d+\]: _nss_mysql_getspnam_r conf file parsing failed/ ) That is correct behaviour of libnss-mysql and caused by a non-root process executing the equivalent of 'getent shadow'. Since this needs to read a password column from the database the configuration file containing the database password is readable by root only. (There is a separate world readable configuration for passwd/group, but the database password contained there should not allow access to the password column). Why is this reported? Is it not possible to configure nss-mysql to not even try to parse that conffile? It looks to me as if this log message reports a (minor) misconfiguration. If it is possible to avoid that message, then it's OK to report it as Unmatched Entry (this is the statement from Bjorn L. from upstream) I had libnss-mysql rebuilt with debugging enabled and checked the debug output comparing it with the code - looking for my configuration error. So I found out, that this message was not an error, but a feature - as long as nss-mysql is working. But if nss_mysql is misconfigured, this message would indicate an error, too. This error message could only be fixed by hacking libnss-mysql. Looking at libnss-mysql again, I found actually two projects (nss-mysql (from which the Debian package libnss-mysql is made) and libnss-mysql (Debian libnss-mysql-bg)) doing more or less the same thing. Perhaps I'll try the other one some day. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390743: logwatch: unmatched postfix-mysql and libnss-mysql log messages
postfix/smtpd messages from auth.log (user/domain info obscured and ran though sort | uniq -c | sort -n): 113 sql plugin create statement from cmusaslsecretCRAM-MD5 user example.com 115 sql plugin create statement from userPassword user example.com 126 begin transaction 126 commit transaction 229 sql plugin Parse the username [EMAIL PROTECTED] 230 sql plugin doing query select password from mail_users where username='[EMAIL PROTECTED]'; 261 sql plugin try and connect to a host 261 sql plugin trying to open db 'dbname' on host '127.0.0.1' 2170 sql auxprop plugin using mysql engine There seems to be no useful information from postfix/smtpd in auth.log. So I'll kill it. or ( $ThisLine =~ /^nss-mysql\[\d+\]: _nss_mysql_getspnam_r conf file parsing failed/ ) That is correct behaviour of libnss-mysql and caused by a non-root process executing the equivalent of 'getent shadow'. Since this needs to read a password column from the database the configuration file containing the database password is readable by root only. (There is a separate world readable configuration for passwd/group, but the database password contained there should not allow access to the password column). Why is this reported? Is it not possible to configure nss-mysql to not even try to parse that conffile? It looks to me as if this log message reports a (minor) misconfiguration. If it is possible to avoid that message, then it's OK to report it as Unmatched Entry (this is the statement from Bjorn L. from upstream) I had libnss-mysql rebuilt with debugging enabled and checked the debug output comparing it with the code - looking for my configuration error. So I found out, that this message was not an error, but a feature - as long as nss-mysql is working. But if nss_mysql is misconfigured, this message would indicate an error, too. I have looked at the source code of libnns-mysql. The only occurence of above message seems to be src/ent.c, line 202: _nss_mysql_log(LOG_ERR,setent(%d): conf file parsing failed, This says LOG_ERR, and I don't think we should kill error messages. However, it would make sense to summarise it, to avoid differnent process numbers to make the list of Unmatched Entries longer. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390743: logwatch: unmatched postfix-mysql and libnss-mysql log messages
Willi Mann wrote:
I have looked at the source code of libnns-mysql. The only occurence of
above message seems to be src/ent.c, line 202:
_nss_mysql_log(LOG_ERR,setent(%d): conf file parsing failed,
This says LOG_ERR, and I don't think we should kill error messages.
However, it would make sense to summarise it, to avoid differnent
process numbers to make the list of Unmatched Entries longer.
No, this is in src/shadow.c, line 278:
if (! _nss_mysql_read_conf_file(shadow,pr)) {
_nss_mysql_log(LOG_ERR,_nss_mysql_getspnam_r conf file
parsing failed);
And this fails on purpose unless it is called by root.
Andreas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390743: logwatch: unmatched postfix-mysql and libnss-mysql log messages
Package: logwatch Version: 7.3.1-2 Severity: normal Hi, postfix-mysql and lib-nss-mysql spit out a few messages that are not recognized in the secure log script. I added the following lines to scripts/services/secure in order to ignore these messages: or ( $ThisLine =~ /^postfix\/smtpd\[\d+\]: sql auxprop plugin using mysql engine/ ) or ( $ThisLine =~ /^postfix\/smtpd\[\d+\]: sql plugin .*/ ) or ( $ThisLine =~ /^postfix\/smtpd\[\d+\]: (begin|commit) transaction/ ) There are quite a few 'sql plugin .*' debug messages and I was to lazy to list them all separately :-) or ( $ThisLine =~ /^nss-mysql\[\d+\]: _nss_mysql_getspnam_r conf file parsing failed/ ) That is correct behaviour of libnss-mysql and caused by a non-root process executing the equivalent of 'getent shadow'. Since this needs to read a password column from the database the configuration file containing the database password is readable by root only. (There is a separate world readable configuration for passwd/group, but the database password contained there should not allow access to the password column). It would be nice if these changes could be integrated into (the debian package of) logwatch. Thanks. Andreas -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable'), (30, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
