qmail - Not_allowed_to_perform_deliveries_as_root

[brooks]

After the upgrade to 8 (CentOS 3.6) qmail won't deliver mail to any of the local (root, postmaster, etc.) aliases. The log shows:

Apr 5 20:32:58 ds qmail: 1144294378.640047 starting delivery 48: msg 3342534 to local [email protected]
Apr 5 20:32:58 ds qmail: 1144294378.640097 status: local 1/10 remote 0/20
Apr 5 20:32:58 ds qmail: 1144294378.642317 delivery 48: deferral: Not_allowed_to_perform_deliveries_as_root./

I started looking at a mail delivery problem with drweb, which by default is set to reject messages that cause a license exception. Drweb allows for 14 users (without a license upgrade) but if some of those 14 users have aliases attached to them it (in theory) causes the license violation which in turn causes a mesage to be generated to "postmaster". To fix that issue all you need to do is change the /etc/drweb/drweb_qmail.conf file from:

LicenseLimit = reject

to

LicenseLimit = pass

One thing always seems to lead to another...

I've see some other posts about drweb dropping mail but nothing specific about the above mentioned problem. Anyone else seeing similar issues?

Although these forums are a good place to communicate they really lack the structure we need to catagorize and discuss the many issues we (unfortunately) see with a new release.

 

[threads]

Did not see this one earlier ... If you try and search for the "Not_allowed....." string, this forum search does not find it!

We seem to have the same issue on RedHat FC3 / Plesk 8

I have been trawling qmail forums all over the place and finally found someone who thought he knew the issue. It seems like qmail takes the UIDs of the various users it requires at compile time so that it does not have to do lookups. Since all Plesk 8 machines should be set up in the same way, this is not problem - until they compile it on a machine where the UID for the "alias" user is zero. From then on, any part of qmail that tries to do anything with aliases fails...

Sending messages back to "postmaster" will probably use the alias feature... they stop.
Sending messages to mailman stops...

I have sent off a few emails to various people to see if we can get a solution - just have to wait and see I guess!

D.J.

 

[brooks]

After waiting for a couple of days for SWSoft support to get back to me I finally decided to dive into this myself. With source code and strace I was able to track the problem down. This is what I sent to SWSoft support who have passed it on to engineering:

------------------------------------------------------

I think I've found the problem. I believe the order of the "conf-users"
file was changed by someone prior to building the qmail RPM under CentOS.
The order should be:

alias
qmaild
qmaill
root
qmailp
qmailq
qmailr
qmails

But, it appears that's not the case given the output of qmail-showctl:

user ids: 0, 2021, 2020, 2022, 2023, 2520, 2521, 2522.

On a pre-8 Plesk box the output of qmail-showctl is:

user ids: 2021, 2020, 2022, 0, 2023, 2520, 2521, 2522.

Also, if you look at the following strace you'll see that qmail-lspawn
is not pulling the "alias" user from the password file, but instead is
using the "root" user, thus causing the failure.

[pid 31380] open("/etc/passwd", O_RDONLY) = 3
[pid 31380] fcntl64(3, F_GETFD) = 0
[pid 31380] fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
[pid 31380] fstat64(3, {st_mode=S_IFREG|0644, st_size=3100, ...}) = 0
[pid 31380] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -
1, 0) = 0xb75e2000
[pid 31380] read(3, "root:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin (deleted the rest of the passwd file output)...
[pid 31380] close(3) = 0
[pid 31380] munmap(0xb75e2000, 4096) = 0
[pid 31380] write(1, "root\0000\0000\0/root\0-\0root\0", 22 <unfinished ...>
[pid 31379] <... read resumed> "root\0000\0000\0/root\0-\0root\0", 128) = 22
[pid 31380] <... write resumed> ) = 22
[pid 31379] read(5, <unfinished ...>
[pid 31380] exit_group(0) = ?
Process 31380 detached
[pid 31379] <... read resumed> "", 128) = 0
[pid 31379] close(5) = 0
[pid 31379] waitpid(31380, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 31380
[pid 31379] fcntl64(2, F_GETFL) = 0x800 (flags O_RDONLY|O_NONBLOCK)
[pid 31379] close(0) = 0
[pid 31379] fcntl64(2, F_DUPFD, 0) = 0
[pid 31379] close(2) = 0
[pid 31379] fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY)
[pid 31379] close(1) = 0
[pid 31379] fcntl64(4, F_DUPFD, 1) = 1
[pid 31379] close(4) = 0
[pid 31379] fcntl64(1, F_GETFL) = 0x1 (flags O_WRONLY)
[pid 31379] close(2) = -1 EBADF (Bad file descriptor)
[pid 31379] fcntl64(1, F_DUPFD, 2) = 2
[pid 31379] setgroups32(1, [0]) = 0
[pid 31379] setgid32(0) = 0
[pid 31379] setuid32(0) = 0
[pid 31379] getuid32() = 0
[pid 31379] exit_group(113) = ?
Process 31379 detached
<... select resumed> ) = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 113}], WNOHANG) = 31379
close(4) = 0
waitpid(-1, 0xbfffa3dc, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0
select(4, [0 3], NULL, NULL, NULL) = 1 (in [3])
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
read(3, "", 128) = 0
write(1, "\0\0ZNot allowed to perform deliveries as root.\n\0", 47) = 47

On a working system you instead see:

[pid 11999] open("/etc/passwd", O_RDONLY) = 3
[pid 11999] fcntl64(3, F_GETFD) = 0
[pid 11999] fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
[pid 11999] fstat64(3, {st_mode=S_IFREG|0644, st_size=3730, ...}) = 0
[pid 11999] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -
1, 0) = 0xb75e9000
[pid 11999] read(3, "root:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin:/bin: / (deleted the rest of the passwd file output)...

[pid 11999] close(3) = 0
[pid 11999] munmap(0xb75e9000, 4096) = 0
[pid 11999] write(1, "alias\0002021\0002020\0/var/qmail/alias\0-\0postmaster\0",
46 <unfinished ...>
[pid 11998] <... read resumed> "alias\0002021\0002020\0/var/qmail/alias\0-\0post
master\0", 128) = 46
[pid 11999] <... write resumed> ) = 46
[pid 11998] read(5, <unfinished ...>
[pid 11999] exit_group(0) = ?

It looks like we'll need to get qmail rebuilt ASAP for the CentOS (3.6) release of Plesk 8 and possibly others. Please let me know when we can expect to see a new RPM, this is a fairly critical bug as no mail to any of the "system maintenance" addresses is working.

------------------------------------------------------

If only SWSoft would release the source RPM we could easily fix this bug, rebuild the RPM, and get on with more important things. Lving in an open source world (of which Plesk is built on) with no way to effect change, except to fire off an email to support, is to say the least, frustrating.

 

[aveldhoven]

Originally posted by brooks
After waiting for a couple of days for SWSoft support to get back to me I finally decided to dive into this myself. With source code and strace I was able to track the problem down. This is what I sent to SWSoft support who have passed it on to engineering:

------------------------------------------------------

If anyone has a resolution to this problem, please let me know, as I'm still trying to figure out what to do.

In the meantime, I replaced user "root" in every vital thing I could imagine.

Like crontabs, Logwatch etc, I just entered a otheremailadres, now I do receive the emails BUT STILL IT IS NOT WORKING ALRIGHT !!!

 

[brooks]

Without souce the only solution is (sadly) to wait for a patch from SWSoft. Installing the qmail RPM from the 7.5.4 might work as a temporary work-around but I'd recommend first testing it on a non-production server.

[netgate@ds tmp]$ rpm -q psa-qmail-1.03 --whatrequires
no package requires psa-qmail-1.03

 

[brooks]

Here's a temporary solution (unitl SWSoft releases a patch).

First make a backup copy of /var/qmail/bin/qmail-getpw (this solution has only minimal testing so you may need to back it out).

cp /var/qmail/bin/qmail-getpw /var/qmail/bin/qmail-getpw.bad

From a server running the same OS but with version 7.5.4 of Plesk copy the /var/qmail/bin/qmail-getpw binary to the server running Plesk 8.

Delivery to aliases defined in /var/qmail/alias will now work. To test it do this:

Create the following file:
----

To: root@my_hostname
From: [email protected]
Subject: Test

Testing...

----

Replacing "my_hostname:" with the name of your server.

Then do:

cat file | /var/qmail|/bin/qmail-inject

You should receive the above message to the destination address defined by the "root" alias.

If anyone needs the 7.5.4/CentOS 3.6 version of the "qmail-getpw" file let me know and I'll be happy to send it to you.

 

[aveldhoven]

Originally posted by brooks
Here's a temporary solution (unitl SWSoft releases a patch).

First make a backup copy of /var/qmail/bin/qmail-getpw (this solution has only minimal testing so you may need to back it out).

cp /var/qmail/bin/qmail-getpw /var/qmail/bin/qmail-getpw.bad

From a server running the same OS but with version 7.5.4 of Plesk copy the /var/qmail/bin/qmail-getpw binary to the server running Plesk 8.

Delivery to aliases defined in /var/qmail/alias will now work. To test it do this:

Create the following file:
----

To: root@my_hostname
From: [email protected]
Subject: Test

Testing...

----

Replacing "my_hostname:" with the name of your server.

Then do:

cat file | /var/qmail|/bin/qmail-inject

You should receive the above message to the destination address defined by the "root" alias.

If anyone needs the 7.5.4/CentOS 3.6 version of the "qmail-getpw" file let me know and I'll be happy to send it to you.

GREAT !!
Works like a charm...

Only is SWSOFT reads this forum...

Anyways.... thanx alot, got my queue almost back to empty now, and im receiving root mails again

 

[threads]

I have also noted that in order to get mailman working again, you need to grab hold of the mm_wrapper program.

The way I did it was:

Grab hold of an older qmail....rpm

(make sure you are somewhere like /root and NOT in the actual root)

rpm2cpio qmail....rpm > qmail.cpio

cpio -i --no-absolute-filenames < qmail.cpio

cp ./var/qmail/bin/mm_wrapper /var/qmail/bin
cp ./var/qmail/bin/qmail-getpw /var/qmail/bin
cp ./var/qmail/bin/qmail-showctl /var/qmail/bin

/usr/local/psa/admin/sbin/mchk --with-spam

/etc/init.d/qmail restart

And things started springing into life for my FC3 installation

-DJ
(phew....)

 

[aveldhoven]

Originally posted by threads
I have also noted that in order to get mailman working again, you need to grab hold of the mm_wrapper program.

The way I did it was:

Grab hold of an older qmail....rpm

(make sure you are somewhere like /root and NOT in the actual root)


And things started springing into life for my FC3 installation

-DJ
(phew....)

Thanx !

This also worked for me.
The only thing to mention is that you have to check if the user popuser belongs to group 110 not to group 101, this was also the case why it didnt work for me.

 

[judouk]

It seems that every time I log into my Plesk server, I have updates to do. However, I'm still using 8.0 (not 8.0.1 or anything).

And.....to my surprise, I still cannot receive emails sent to root (like logwatch for example).

I notice that brooks opened a ticket with support, which subsequently got pushed over to engineering - but where is the fix.

Come on SWSOFT - this is a problem

 

[brooks]

I did hear back from them yesterday. They informed me that the problem has been fixed and will be released in an upcoming update.

I couldn't agree with you more about how long it takes them to get a patch out, especially to what looks like a simple fix (recompile with the correct settings). I guess they see this as an annoyance bug, but to anyone responsible for the health of a server it's a lot more than an annoyance.

Sadly, at least from my perspective, Plesk has become more about interface design and less about providing innovative features (if you call awstats innovative). Features that give providers and end users choice (stats, webmail, etc.) and providers the tools they need (reporting, communications, resource management, etc.) seem to never make it into the product. Instead we end up with yet another level (view really) in the interface. But, I've digressed (time to get back on track).

The good news is that a fix is "in the mail".

 

[judouk]

In the mail....hmmm, I wonder if this will be US ground........

 

[NightStorm]

Originally posted by brooks
The good news is that a fix is "in the mail".

If they're sending it through Plesk mail, we may never get it.

 

[pangeles]

Webmail/Qmail Fix? Patch ETA

So they are sending a fix sometime in the near future? Everyone in my group is wigging out due to the lack of email...

Any timeline from SWsoft regarding this elusive patch?

 

[hedererjs]

"cpio -i --no-absolute-filenames < qmail.cpio"

=> this doesn't work for me. I've got a lot of "No such file or directory"

 

[hedererjs]

I tried "cp /var/qmail/bin/qmail-getpw /var/qmail/bin/qmail-getpw.bad"

and all mails in queue were rejected!

 

[Tischi]

Originally posted by hedererjs
I tried "cp /var/qmail/bin/qmail-getpw /var/qmail/bin/qmail-getpw.bad"

and all mails in queue were rejected!

You need the old qmail-getpw from plesk 7.x
Can somebody upload it?

 

[hedererjs]

Originally posted by Tischi
You need the old qmail-getpw from plesk 7.x
Can somebody upload it?

my ISP gave me the one from 7.5.4 on FC3 and it rejected every message

if you've got another version => hedererjs at free.fr (corrected)

 

[hedererjs]

It seems that it's all in order back!!!!

Yahoo!!!!

I deleted /opt/drweb/spool in which there were tons of files generated during my server overflow and it gave my queue a new life!!

and with my current psa-qmail version

 

[Tischi]

my spool directorys are all empty