[Bug 1916541] Re: smtp "fatal: unknown service: smtp/tcp", probably after libc upgrade
Bug Watch Updater
1916541 at bugs.launchpad.net
Fri Mar 12 06:41:34 UTC 2021
Launchpad has imported 7 comments from the remote bug at
https://sourceware.org/bugzilla/show_bug.cgi?id=27389.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2021-02-10T08:19:18+00:00 Sjon-8 wrote:
I have an issue that I suspect is caused by a recent glibc change, but I
haven't 100% ruled out another cause, so this report might be bogus.
I use PHP-FPM [1] with chroots enabled. Since upgrading glibc, name
resolving (via DNS) fails with "getaddrinfo failed: System error" in my
chroot and I'm pretty sure it is caused by the recently added "Block
attempts to dlopen any module we haven't already opened" [2]
What seems to happen is that the PHP-FPM master process only loads
libnss_files.so.2 and libnss_systemd.so.2 because it uses that to
resolve the username (it matches nsswitch which contains: "passwd: files
systemd")
If any of the FPM workers then attempts to perform dns resolving, that
fails because libnss_dns.so.2 has not been loaded yet (even though I
made it available in the chroot), and due to the recent change, it won't
be loaded either.
I have confirmed I can "fix" it by forcing the fpm master to load the
dns module by modifying nsswitch.conf outside of the chroot to contains
"passwd: dns files systemd", this fixes it
1. https://www.php.net/manual/en/install.fpm.php
2. https://github.com/bminor/glibc/commit/429029a73ec2dba7f808f69ec8b9e3d84e13e804#diff-9305f1992144bc8c923a840d44827642f1c3f57e3df85a69357fff2fe7370fb8R352
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/0
------------------------------------------------------------------------
On 2021-02-10T08:41:14+00:00 Sjon-8 wrote:
Some more information for clarification:
# grep dns /etc/nsswitch
hosts: files dns
# strace -eopenat -f /usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf 2>&1|grep nss
openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 22
# curl https://localhost/test.php
getaddrinfo failed: System error
--
# grep dns /etc/nsswitch
passwd: dns files systemd
hosts: files dns
# strace -eopenat -f /usr/bin/php-fpm --nodaemonize --fpm-config /etc/php/php-fpm.conf 2>&1|grep nss
openat(AT_FDCWD, "/etc/ssl/openssl.cnf", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 22
openat(AT_FDCWD, "/usr/lib/libnss_systemd.so.2", O_RDONLY|O_CLOEXEC) = 22
# curl https://localhost/test.php
works
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/1
------------------------------------------------------------------------
On 2021-02-16T12:45:06+00:00 Florian Weimer wrote:
I've started a discussion on libc-alpha:
NSS chroot protection
https://sourceware.org/pipermail/libc-alpha/2021-February/122714.html
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/2
------------------------------------------------------------------------
On 2021-02-16T14:47:04+00:00 Howard Chu wrote:
(In reply to Florian Weimer from comment #2)
> I've started a discussion on libc-alpha:
>
> NSS chroot protection
> https://sourceware.org/pipermail/libc-alpha/2021-February/122714.html
Can you link to more context on what security regressions this change
was meant to address? chrooted servers have been running for decades
using the NSS databases of the chroot jail, and this change breaks all
of them.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/3
------------------------------------------------------------------------
On 2021-02-16T14:50:52+00:00 Florian Weimer wrote:
It's CVE-2019-14271:
https://nvd.nist.gov/vuln/detail/CVE-2019-14271
(The Docker fix is likely incomplete depending on nsswitch.conf
contents.)
That issue is of no concern once the service is running, it applies to
the construction of the chroot contents from the outside.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/4
------------------------------------------------------------------------
On 2021-03-04T11:46:50+00:00 Florian Weimer wrote:
Fixed for 2.34. Also backported to 2.33.
commit 58673149f37389495c098421085ffdb468b3f7ad
Author: DJ Delorie <dj at redhat.com>
Date: Thu Feb 18 15:26:30 2021 -0500
nss: Re-enable NSS module loading after chroot [BZ #27389]
The glibc 2.33 release enabled /etc/nsswitch.conf reloading,
and to prevent potential security issues like CVE-2019-14271
the re-loading of nsswitch.conf and all mdoules was disabled
when the root filesystem changes (see bug 27077).
Unfortunately php-lpfm and openldap both require the ability
to continue to load NSS modules after chroot. The packages
do not exec after the chroot, and so do not cause the
protections to be reset. The only solution is to re-enable
only NSS module loading (not nsswitch.conf reloading) and so
get back the previous glibc behaviour.
In the future we may introduce a way to harden applications
so they do not reload NSS modules once the root filesystem
changes, or that only files/dns are available pre-loaded
(or builtin).
Reviewed-by: Carlos O'Donell <carlos at redhat.com>
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/15
------------------------------------------------------------------------
On 2021-03-11T08:13:57+00:00 Eugene Crosser wrote:
Just as a note, the change has also broken postfix. Its smtp client
enters chroot after start, and then down the road calls
`getservbyname()` which fails.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1916541/comments/18
** Changed in: glibc
Status: Unknown => Fix Released
** Changed in: glibc
Importance: Unknown => Medium
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-14271
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1916541
Title:
smtp "fatal: unknown service: smtp/tcp", probably after libc upgrade
Status in GLibC:
Fix Released
Status in glibc package in Ubuntu:
In Progress
Status in postfix package in Ubuntu:
Invalid
Status in glibc source package in Hirsute:
In Progress
Status in postfix source package in Hirsute:
Invalid
Bug description:
On hirsute, on Jan 20, postfix stopped sending outgoing mails with the
error
Feb 22 23:35:18 pccross postfix/smtp[9582]: fatal: unknown service:
smtp/tcp
There were no changes in the system other than daily upgrades.
Strace shows that `smtp` process (while chrooted), after successful
open of the file in the queue, tried to use NSS, ran `fstat()` against
`/etc/nsswitch.conf`, that succeeded (presumably using the copy in the
/var/spool/postfix/etc/ directory), but there was no subsequent
`open()`, and the next syscall is `sendto()` of the error message to
syslog.
There was a big upgrade between the last successful and the first
unsuccessful email delivery, and among other things libc was updated
from 2.32-0ubuntu6 to 2.33-0ubuntu2. I suspect that there was some
change in the NSS in libc that resulted in the failure of
`getservbyname()`.
Is anybody else observing this problem?
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: postfix 3.5.6-1
ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11
Uname: Linux 5.10.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu59
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: X-Cinnamon
Date: Tue Feb 23 00:02:13 2021
EtcMailname: pccross.average.org
Hostname: pccross
PostconfMydomain: localdomain
PostconfMyhostname: pccross.localdomain
PostconfMyorigin: /etc/mailname
ResolvConf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search average.org
SourcePackage: postfix
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1916541/+subscriptions
More information about the foundations-bugs
mailing list