Tumbleweed can't get amavisd to start
Hope this is the correct place to post this. New to Tumblewed not new to openSuSE New install of Tumbleweed on new server. Can't get postfix to deliver mail it gets a 421 when trying to talk to port 10025 I don't think it's firewall related because amavisd fails to start with: Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis/Conf.pm line 1038. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. So is that indicating there are two distinct errors? PATH and Perl? Logged into the server checked all the directories I see in the PATH all are 755. This same postfix conf (older version though) is running on another openSuSE server and for the life of me I cannot find what is different so I'm stumped at the moment as to why.
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 12:48:33 -0500 Hope this is the correct place to post this. New to Tumblewed not new to openSuSE New install of Tumbleweed on new server. Can't get postfix to deliver mail it gets a 421 when trying to talk to port 10025 I don't think it's firewall related because amavisd fails to start with: Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis/Conf.pm line 1038. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. So is that indicating there are two distinct errors? PATH and Perl? Logged into the server checked all the directories I see in the PATH all are 755. According to "man perldiag" (albeit for perl 5.26.1 under openSUSE Leap 15.5, though I don't expect any different for later Perl versions), the entry for "Insecure directory ..." also says "... the PATH must not contain any relative directory." IME, "." is the usual offender. This same postfix conf (older version though) is running on another openSuSE server and for the life of me I cannot find what is different so I'm stumped at the moment as to why. This is not about Postfix, but about how amavisd is started. I looked at the current version of Net::Domain as distributed from CPAN [1] and in the repo [2] and that is certainly not what has changed. Line 173 uses backticks to invoke "domainname", so if you pruned PATH judiciously in the script that starts amavisd, that ought to be enough. -- Bob Rogers http://www.rgrjr.com/ [1] https://metacpan.org/pod/Net::Domain [2] https://github.com/steve-m-hay/perl-libnet/blame/master/lib/Net/Domain.pm
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links? PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin" lrwxrwxrwx 1 root root 8 Dec 8 2023 /sbin -> usr/sbin drwxr-xr-x 2 root root 20480 Jun 25 16:23 /usr/sbin drwxr-xr-x 2 root root 4096 Sep 25 2014 /usr/local/sbin drwxr-xr-x 2 root root 4096 Dec 8 2023 /root/bin drwxr-xr-x 2 root root 4096 Jun 10 20:49 /usr/local/bin dr-xr-xr-x 2 root root 81920 Jun 23 16:08 /usr/bin lrwxrwxrwx 1 root root 7 Dec 8 2023 /bin -> usr/bin # ls -ald /bin /usr/bin /sbin /usr/sbin lrwxrwxrwx 1 root root 7 Dec 8 2023 /bin -> usr/bin lrwxrwxrwx 1 root root 8 Dec 8 2023 /sbin -> usr/sbin dr-xr-xr-x 2 root root 81920 Jun 23 16:08 /usr/bin drwxr-xr-x 2 root root 20480 Jun 25 16:23 /usr/sbin Which might be the case because on the server that is working /sbin and /bin are *not* links: drwxr-xr-x 2 root root 12288 Jan 28 2021 /sbin drwxr-xr-x 2 root root 20480 Jun 25 00:00 /usr/sbin drwxr-xr-x 2 root root 4096 Sep 25 2014 /usr/local/sbin drwxr-xr-x 2 root root 4096 Sep 25 2014 /root/bin drwxr-xr-x 2 root root 4096 Jun 10 20:49 /usr/local/bin drwxr-xr-x 2 root root 69632 May 9 14:13 /usr/bin drwxr-xr-x 2 root root 4096 Jan 28 2017 /bin On 6/25/24 13:46, Bob Rogers wrote:
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 12:48:33 -0500
Hope this is the correct place to post this. New to Tumblewed not new to openSuSE
New install of Tumbleweed on new server. Can't get postfix to deliver mail it gets a 421 when trying to talk to port 10025 I don't think it's firewall related because amavisd fails to start with:
Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis/Conf.pm line 1038. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27.
So is that indicating there are two distinct errors? PATH and Perl? Logged into the server checked all the directories I see in the PATH all are 755.
According to "man perldiag" (albeit for perl 5.26.1 under openSUSE Leap 15.5, though I don't expect any different for later Perl versions), the entry for "Insecure directory ..." also says "... the PATH must not contain any relative directory." IME, "." is the usual offender.
This same postfix conf (older version though) is running on another openSuSE server and for the life of me I cannot find what is different so I'm stumped at the moment as to why.
This is not about Postfix, but about how amavisd is started. I looked at the current version of Net::Domain as distributed from CPAN [1] and in the repo [2] and that is certainly not what has changed. Line 173 uses backticks to invoke "domainname", so if you pruned PATH judiciously in the script that starts amavisd, that ought to be enough.
-- Bob Rogers http://www.rgrjr.com/
[1] https://metacpan.org/pod/Net::Domain
[2] https://github.com/steve-m-hay/perl-libnet/blame/master/lib/Net/Domain.pm
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 16:46:17 -0500 Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links? It shouldn't, because link permissions can only revoke bits (IIRC), rather than grant additional ones. PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin" lrwxrwxrwx 1 root root 8 Dec 8 2023 /sbin -> usr/sbin . . . lrwxrwxrwx 1 root root 7 Dec 8 2023 /bin -> usr/bin Odd that /bin and /sbin are symbolic links; odder still that they are links to other standard program directories, since both pairs ought to exist. Oddest of all that they are expressed as relative pathnames. Which might be the case because on the server that is working /sbin and /bin are *not* links . . . On the off chance that it's choking on the fact that they are relative links, you could try using a PATH without /bin and /sbin, since (as you've shown) these two directories are redundant. Really, that shouldn't matter, since relative link targets are interpreted with respect to the link directory. So if it works, that would have to be a bug in that version of Perl. But since it's a real difference you've found between the two installations, it could be worth a try. -- Bob
Thanks. I thought of removing /sbin and /bin from the path but without the links what if something is looking for /sbin/ProgramA or /bin/ProgramB it's not going to find them. And, I would have to do that and how would I do that so that /sbin and /bin are not in the PATH at boot? Done globally that could brick the boot and if I were to how wouId do that for only amavisd and then some update could reverse it. I don't get this, if this is a bug i.e. it's kinda like WoW! -Curt On 6/25/24 17:17, Bob Rogers wrote:
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 16:46:17 -0500
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
It shouldn't, because link permissions can only revoke bits (IIRC), rather than grant additional ones.
PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin"
lrwxrwxrwx 1 root root 8 Dec 8 2023 /sbin -> usr/sbin . . . lrwxrwxrwx 1 root root 7 Dec 8 2023 /bin -> usr/bin
Odd that /bin and /sbin are symbolic links; odder still that they are links to other standard program directories, since both pairs ought to exist. Oddest of all that they are expressed as relative pathnames.
Which might be the case because on the server that is working /sbin and /bin are *not* links . . .
On the off chance that it's choking on the fact that they are relative links, you could try using a PATH without /bin and /sbin, since (as you've shown) these two directories are redundant. Really, that shouldn't matter, since relative link targets are interpreted with respect to the link directory. So if it works, that would have to be a bug in that version of Perl. But since it's a real difference you've found between the two installations, it could be worth a try.
-- Bob
and I just tried removing /sbin and /bin from the PATH. No joy. PATH="/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin" drwxr-xr-x 2 root root 20480 Jun 25 16:23 /usr/sbin drwxr-xr-x 2 root root 4096 Sep 25 2014 /usr/local/sbin drwxr-xr-x 2 root root 4096 Dec 8 2023 /root/bin drwxr-xr-x 2 root root 4096 Jun 10 20:49 /usr/local/bin dr-xr-xr-x 2 root root 81920 Jun 23 16:08 /usr/bin / # amavisd Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis/Conf.pm line 1038. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. On 6/25/24 18:40, Curtis J Blank wrote:
Thanks.
I thought of removing /sbin and /bin from the path but without the links what if something is looking for /sbin/ProgramA or /bin/ProgramB it's not going to find them.
And, I would have to do that and how would I do that so that /sbin and /bin are not in the PATH at boot? Done globally that could brick the boot and if I were to how wouId do that for only amavisd and then some update could reverse it.
I don't get this, if this is a bug i.e. it's kinda like WoW!
-Curt
On 6/25/24 17:17, Bob Rogers wrote:
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 16:46:17 -0500
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
It shouldn't, because link permissions can only revoke bits (IIRC), rather than grant additional ones.
PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin"
lrwxrwxrwx 1 root root 8 Dec 8 2023 /sbin -> usr/sbin . . . lrwxrwxrwx 1 root root 7 Dec 8 2023 /bin -> usr/bin
Odd that /bin and /sbin are symbolic links; odder still that they are links to other standard program directories, since both pairs ought to exist. Oddest of all that they are expressed as relative pathnames.
Which might be the case because on the server that is working /sbin and /bin are *not* links . . .
On the off chance that it's choking on the fact that they are relative links, you could try using a PATH without /bin and /sbin, since (as you've shown) these two directories are redundant. Really, that shouldn't matter, since relative link targets are interpreted with respect to the link directory. So if it works, that would have to be a bug in that version of Perl. But since it's a real difference you've found between the two installations, it could be worth a try.
-- Bob
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 19:04:55 -0500 and I just tried removing /sbin and /bin from the PATH. No joy. PATH="/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin" drwxr-xr-x 2 root root 20480 Jun 25 16:23 /usr/sbin drwxr-xr-x 2 root root 4096 Sep 25� 2014 /usr/local/sbin drwxr-xr-x 2 root root 4096 Dec� 8� 2023 /root/bin drwxr-xr-x 2 root root 4096 Jun 10 20:49 /usr/local/bin dr-xr-xr-x 2 root root 81920 Jun 23 16:08 /usr/bin / # amavisd Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis/Conf.pm line 1038. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.38.2/Amavis.pm line 27. Well, that answers that question. Not that I'm greatly surprised. Looking at the docs, domainname only produces the NIS/YP domain name, which (I am guessing) you are probably not using; neither am I. I find that on my desktop system, Net::Domain produces the FQDN by looking in /etc/resolv.conf and picking the name out of the *last* "search" or "domain" line that it sees. Maybe that's the difference between your configurations? -- Bob P.S. Sorry for the resend; I got distracted by a power failure and forgot to include the list.
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 18:40:34 -0500 Thanks. I thought of removing /sbin and /bin from the path but without the links what if something is looking for /sbin/ProgramA or /bin/ProgramB it's not going to find them. I'm not saying to change the links, just PATH, and just for amavisd. And, I would have to do that and how would I do that so that /sbin and /bin are not in the PATH at boot? Done globally that could brick the boot and if I were to how wouId do that for only amavisd and then some update could reverse it. If you set the PATH in amavisd.service (or whatever systemd calls it, and I'm assuming that's the right place) and restarted, that would only affect amavisd. You'd still have the update problem, but you could test the Postfix/amavisd interaction, and if it worked, then worry about making it permanent. I don't get this, if this is a bug i.e. it's kinda like WoW! -Curt Yes, which is why I find it hard to believe that this is really the problem. On the other hand, if somebody made an over-zealous change to Perl, it might not have been noticed, because this can't be a common situation. -- Bob
On 26.06.2024 00:46, Curtis J Blank wrote:
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
No. It is not about the content of the $PATH, but about the fact that it is imported from the external environment. bor@tw:~> PATH=/usr/bin perl -Te 'use Net::Domain; $foo = `domainname`' Insecure $ENV{PATH} while running with -T switch at -e line 1. bor@tw:~> perl -Te 'use Net::Domain; $ENV{PATH}="/usr/bin"; $foo = `domainname`' bor@tw:~>
Thanks. I see that now. But what is the fix for this then to get amavisd running? On 6/25/24 23:45, Andrei Borzenkov wrote:
On 26.06.2024 00:46, Curtis J Blank wrote:
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
No. It is not about the content of the $PATH, but about the fact that it is imported from the external environment.
bor@tw:~> PATH=/usr/bin perl -Te 'use Net::Domain; $foo = `domainname`' Insecure $ENV{PATH} while running with -T switch at -e line 1. bor@tw:~> perl -Te 'use Net::Domain; $ENV{PATH}="/usr/bin"; $foo = `domainname`' bor@tw:~>
I filed a bug report. Don't know what else to do. On 6/26/24 10:56, Curtis J Blank wrote:
Thanks. I see that now. But what is the fix for this then to get amavisd running?
On 6/25/24 23:45, Andrei Borzenkov wrote:
On 26.06.2024 00:46, Curtis J Blank wrote:
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
No. It is not about the content of the $PATH, but about the fact that it is imported from the external environment.
bor@tw:~> PATH=/usr/bin perl -Te 'use Net::Domain; $foo = `domainname`' Insecure $ENV{PATH} while running with -T switch at -e line 1. bor@tw:~> perl -Te 'use Net::Domain; $ENV{PATH}="/usr/bin"; $foo = `domainname`' bor@tw:~>
I think I found the problem. The reported error: "amavis[]: Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173." is totally bogus and has nothing to do with the problem. It appears the hostname has to be a FQDN. Having hostname set to the host name and domainame set to the domain name is not adequate. When hostname is a FQDN amavisd starts without error. The same config with the hostname *not* being FQDN on my current postfix email server using amavisd also is and has been running that way since at least 2014 if not 2011. On 6/26/24 12:38, Curtis J Blank wrote:
I filed a bug report. Don't know what else to do.
On 6/26/24 10:56, Curtis J Blank wrote:
Thanks. I see that now. But what is the fix for this then to get amavisd running?
On 6/25/24 23:45, Andrei Borzenkov wrote:
On 26.06.2024 00:46, Curtis J Blank wrote:
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
No. It is not about the content of the $PATH, but about the fact that it is imported from the external environment.
bor@tw:~> PATH=/usr/bin perl -Te 'use Net::Domain; $foo = `domainname`' Insecure $ENV{PATH} while running with -T switch at -e line 1. bor@tw:~> perl -Te 'use Net::Domain; $ENV{PATH}="/usr/bin"; $foo = `domainname`' bor@tw:~>
From: Curtis J Blank <curt@curtronics.com> Date: Wed, 26 Jun 2024 14:14:37 -0500 I think I found the problem. The reported error: "amavis[]: Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173." is totally bogus and has nothing to do with the problem. Indeed, the fact that Net::Domain uses domainname at all is bogus, since domainname returns the NIS domain, which has nothing to do with Internet domains. Net::Domain seems to work fine on my system without that code, and without hostname set to a FQDN (and without the /etc/resolv.conf hack I mentioned yesterday), so I may propose this as a fix to the maintainer. (Not that any such fix would be released soon enough to do you any good.) It appears the hostname has to be a FQDN. Having hostname set to the host name and domainame set to the domain name is not adequate. Not necessarily . . . When hostname is a FQDN amavisd starts without error. The same config with the hostname *not* being FQDN on my current postfix email server using amavisd also is and has been running that way since at least 2014 if not 2011. The key is how Net::Domain constructs the FQDN, since Net::Domain has several ways of finding the domain name and tacking it onto a bare hostname. Besides that /etc/resolv.conf hack, it looks at what gethostbyname returns for local host names to see if any of those have domains, and uses the LOCALDOMAIN and DOMAIN environment variables as a last resort. In short, you have other options beyond changing hostname. -- Bob
Ah ha! Thanks! Your explanation made me think of something that might be the difference between my two servers and why the new one needs the hostname set to a FQDN. /etc/resolv.conf The new server only had one entry, one nameserver. The existing server has two nameservers listed and a "search <myDomain>" entry. Oversight on my part. Put the second entry and search statement in resolv.conf on the new server. Then on the new server set the hostname to just the servers name and cleared domainname so it then matched the old server's configuration and amavisd successfully starts. I'm betting having the search in resolv.conf is the key. -Curt On 6/26/24 14:58, Bob Rogers wrote:
From: Curtis J Blank <curt@curtronics.com> Date: Wed, 26 Jun 2024 14:14:37 -0500
I think I found the problem. The reported error: "amavis[]: Insecure directory in $ENV{PATH} while running with -T switch at /usr/lib/perl5/5.38.2/Net/Domain.pm line 173." is totally bogus and has nothing to do with the problem.
Indeed, the fact that Net::Domain uses domainname at all is bogus, since domainname returns the NIS domain, which has nothing to do with Internet domains. Net::Domain seems to work fine on my system without that code, and without hostname set to a FQDN (and without the /etc/resolv.conf hack I mentioned yesterday), so I may propose this as a fix to the maintainer. (Not that any such fix would be released soon enough to do you any good.)
It appears the hostname has to be a FQDN. Having hostname set to the host name and domainame set to the domain name is not adequate.
Not necessarily . . .
When hostname is a FQDN amavisd starts without error. The same config with the hostname *not* being FQDN on my current postfix email server using amavisd also is and has been running that way since at least 2014 if not 2011.
The key is how Net::Domain constructs the FQDN, since Net::Domain has several ways of finding the domain name and tacking it onto a bare hostname. Besides that /etc/resolv.conf hack, it looks at what gethostbyname returns for local host names to see if any of those have domains, and uses the LOCALDOMAIN and DOMAIN environment variables as a last resort.
In short, you have other options beyond changing hostname.
-- Bob
From: Curtis J Blank <curt@curtronics.com> Date: Wed, 26 Jun 2024 17:55:56 -0500 Ah ha! Thanks! Your explanation made me think of something that might be the difference between my two servers and why the new one needs the hostname set to a FQDN. /etc/resolv.conf The new server only had one entry, one nameserver. The existing server has two nameservers listed and a "search <myDomain>" entry. Oversight on my part. Put the second entry and search statement in resolv.conf on the new server. Yes, that would certainly explains it. Then on the new server set the hostname to just the servers name and cleared domainname so it then matched the old server's configuration and amavisd successfully starts. I'm betting having the search in resolv.conf is the key. -Curt It works, and I'm glad you're out of the woods now, but this all seems pretty hackish to me. Especially since (I just learned) that Amavis lets you set the server host name explicitly in amavisd.conf in the $myhostname variable [1], and so it's just using Net::Domain to compute a default. At the very least, it should catch errors like these and say "Please set $myhostname" instead of dying obscurely. You may want to submit an Amavis bug report. Interestingly, a little googling shows that failing in Net::Domain is something of a FAQ, going back to 2005 [2]. The nest-to-last post on that thread shows that it does produce a proper error message that explains the problem (as of release 2.2.3, 22-Aug-2005 [3]) when it doesn't die unexpectedly. -- Bob [1] https://github.com/aosm/amavisd/blob/master/amavisd/amavisd-new-2.6.6/amavis...; see line 73. [2] https://bugs.launchpad.net/ubuntu/+source/amavisd-new/+bug/251377 [3] https://gitlab.com/amavis/amavis/-/blob/master/RELEASE_NOTES?ref_type=heads; see line 11579.
From: Andrei Borzenkov <arvidjaar@gmail.com> Date: Wed, 26 Jun 2024 07:45:47 +0300 On 26.06.2024 00:46, Curtis J Blank wrote:
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
No. It is not about the content of the $PATH, but about the fact that it is imported from the external environment. bor@tw:~> PATH=/usr/bin perl -Te 'use Net::Domain; $foo = `domainname`' Insecure $ENV{PATH} while running with -T switch at -e line 1. bor@tw:~> perl -Te 'use Net::Domain; $ENV{PATH}="/usr/bin"; $foo = `domainname`' bor@tw:~> That's a different error. The original error is Insecure directory in $ENV{PATH} while running with -T switch ... I can reproduce that as follows: rogers@orion> perl -Te 'use Net::Domain; $ENV{PATH}="/usr/bin:."; $foo = `domainname`' Insecure directory in $ENV{PATH} while running with -T switch at -e line 1. rogers@orion> This is just your second Perl one-liner with "." added to the untainted $ENV{PATH}. Here's the entire description of the error message from "man perldiag" on my system: Insecure directory in %s (F) You can't use system(), exec(), or a piped open in a setuid or setgid script if $ENV{PATH} contains a directory that is writable by the world. Also, the PATH must not contain any relative directory. See perlsec. So the original error is about the value itself, rather than the source. It's still a mystery why Curtis saw this error in the amavisd context, but that's now academic (and, as I've said, I think it's a bug in Net::Domain that it calls domainname at all). -- Bob
participants (3)
-
Andrei Borzenkov -
Bob Rogers -
Curtis J Blank