7

If I run postfix check on my debian squeeze server, I get this:

postfix/postfix-script: warning: /var/spool/postfix/lib/libnss_nisplus-2.11.3.so and /lib/libnss_nisplus-2.11.3.so differ
postfix/postfix-script: warning: /var/spool/postfix/lib/libnss_files-2.11.3.so and /lib/libnss_files-2.11.3.so differ
postfix/postfix-script: warning: /var/spool/postfix/lib/libnss_compat-2.11.3.so and /lib/libnss_compat-2.11.3.so differ
postfix/postfix-script: warning: /var/spool/postfix/lib/libnss_hesiod-2.11.3.so and /lib/libnss_hesiod-2.11.3.so differ
postfix/postfix-script: warning: /var/spool/postfix/lib/libnss_nis-2.11.3.so and /lib/libnss_nis-2.11.3.so differ
postfix/postfix-script: warning: /var/spool/postfix/lib/libnss_dns-2.11.3.so and /lib/libnss_dns-2.11.3.so differ

Somebody know a solution to fix this ?

4 Answers 4

5

/var/spool/postfix is a chroot where postfix can optionally run, The idea is that if postfix is somehow compromised, the only thing the attacker would have access to is this small subset of your system instead of your whole system. The warning here is that the files in /var/spool/postfix no longer match the files in your regular system that they were copied from. You might verify that the files in /lib were expected to change (like, was libnss recently upgraded?), then consider copying these versions into the /var/spool/postfix/ chroot, so that the chroot also gets this upgrade.

3

Nowadays (at least with Ubuntu server) you can fix this issue by restarting the Postfix service simply by running either

sudo systemctl restart postfix

or

sudo service postfix restart

(Both do exactly the same thing on modern Linux systems – I prefer the service command because it already worked pre-systemd era but I'm pretty sure the systemd variant with systemctl is the officially recommended one.)

This works because Postfix creates the chroot environment during the service start but doesn't follow modified files when you apply security updates. As a result, these files may differ when you have been running Postfix for long enough and installed security updates without rebooting the whole system (which is usually not required).

The files in /var/spool/... are the historical versions that were installed in the system the last time Postfix was started and the startup scripts copy those files to chroot that Postfix builds during the startup. When you run postfix, it checks if the files in /var/spool/... matches the files in the system. And this check fails if the packages containing those libraries have been updated while Postfix has been running. If the libraries contain security patches to features that Postfix uses, you should have already restarted Postfix or installing the security patches has been ineffective. If the changed library versions didn't have fixes for the features that Postfix actually uses, you can safely ignore the warning.

If you always restart the all affected services after installing security updates you should hit this case very rarely.

2

As per stew's answer, to kindly save people typing. As root:

cd /lib; cp libnss_files-2.11.3.so libnss_nis-2.11.3.so libnss_dns-2.11.3.so libnss_compat-2.11.3.so libnss_nisplus-2.11.3.so libnss_hesiod-2.11.3.so /var/spool/postfix/lib/

0

My comment is not an answer to this question, but I think it is still relevant mainly because I see this as another symptom of the issue originally posted. I spent hours searching the Internet on why I was getting this error:

Recipient address rejected: User unknown in local recipient table

whenever I tried to send an email to my new user account. As it turns out the underlying issue was the fact that Postfix is using a chroot. All I had to do was restart the Postfix service after creating the new user account and the chroot copy of passwd got updated and the error stopped. Up until finding this post everything I was finding was going on about domain setup (either in DNS or the mail server host), problems with the mail.cf setup, or the need to do something like setup virtual mailboxes. But, when I found this post I discovered Postfix has a chroot and when I checked it, sure enough, my /etc/passwd file had the new account, while the chroot passwd file did not.

So, just wanted to add this note here for others that are getting their mail rejected and don't know that Postfix uses a chroot.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .