Incoming mail : Which user run a script in a .qmail-name ?


Here is my problem. The perl binary is allowed to only few users whom are in a group called Perl.

We have :

-rwxr-x---    2 root     perl        12492 Jun 10 19:33 /usr/bin/perl

Our problem with this is that we have some mail piping which launch a perl script. For example the mail .qmail-support contains:


Every times a mail is sent to support@mydomain we have an error in the /var/log/send/current log file like this one :

@40000000456743ab158d4fa4 delivery 224282: deferral: /bin/sh:/home/account/domain/html/secure/support/include/email.cgi:/usr/bin/perl:_bad_interpreter:_Permission_denied/

The permission to access Perl is denied.

So my question is simple, which user we have to add to the perl group to allow incoming mail to execure perl ?

We’ve tried to add all these users to the perl group but we still have this pbm


hmmm… A last idea, does this user must have an active shell associated to himself and not /sbin/nologin ?

Thanks for your help


We’ve tried this setup as well, and we could never get it to work, and resorted to ‘chmod a+x /usr/bin/perl’. Not sure if we looked into the user shell idea though.

ok thanks Socheat.

Do you know which user is involved in when there is an email piping ? which user launch the script ?


That’s the strange thing. If you look in the logs, you’ll clearly see that uid 108 is executing the .qmail-* file, which is the qmail user, but adding that qmail user to the perl group doesn’t work. We tried adding all the qmail users to the perl group just like you did, and both the vpopmail and vchkpw user. None of that worked.

If you find an answer, please share with the rest of us. :slight_smile:

I had a similar situation piping email from a cgi script here:

Which I think the “real” answer turned out to be Paul’s, with:

If you’re going to make the permissions 600, you’ll want the owner of the dot-qmail file to be the vpopmail user. Also, the vpopmail user should be able to read and execute the cgi. It would probably be easiest to make the cgi world read and executable.


[QUOTE=JayBaen;10615]I had a similar situation piping email from a cgi script here:

Which I think the “real” answer turned out to be Paul’s, with:


It isn’t.

Our .qmail-support is owned by vpopmail
The cgi script is world readable and executable

Qmail-support has :

-rw------- 1 vpopmail account

cgi script has

-rwxr-xr-x 1 account account

In fact email-piping works great if the perl binary is set executable to world. I mean if /usr/bin/perl has -rwxr-xr-x

But if perl has -rwxr-x— and vpopmail is IN the perl group, which has executable rights on perl bin, then it doesn’t work.

I tried to change the .qmail-support file to give it these rights (+x for vpopmail owner) :

-rwx------ 1 vpopmail account

But in this last case I have this error in /var/log/send/current

@4000000045687ce71943ef04 delivery 6065: deferral: Uh-oh:_.qmail_has_prog_delivery_but_has_x_bit_set._(#4.7.0)/

Qmail/vpopmail doesn’t like the .qmail- file has the x bit set !!! :confused:

So as Socheat told, for yet I have tried a lot of things and none of them work. The only solution is to have the perl bin set World executable. For me it is no so good. Not give world executable authority to the perl binary was a good solution to current and main attacks in /tmp folder (with wget then launch script with perl). :cool:

Anyway, we have mount the /tmp dir with noexec and we have set wget not world executable

If somebody find the solution I pay him a bottle of champagne directly from France (where I am) for Christmas !!! :slight_smile:


You are right - I’ve got:

16 -rwxr-xr-x  2 root root 15160 Aug 12 18:25 perl

Which makes it all work well.

(I know this doesn’t help, but at least doubly-confirms what you’re seeing).


Hi Pascal,

Not an ideal solution, but one that does work is to take a copy of the perl wrapper (/usr/bin/perl), chown it to vpopmail:vchkpw and chmod 700 so no-one else can execute it.

Then, in your .qmail-name file, reference it as follows:

|/path/to/perlwrapper /path/to/script

It is running as vpopmail BTW; this looks to be a qmail permissions thing more than anything else.