Virtualmin Pro Mail alias destination "feed to program" has owner permission issue: Executed as "nobody" instead of user

Submitted by beat on Tue, 02/05/2013 - 06:33

A user has tried adding a program as a mail alias destination:

/bin/sh -c '/usr/bin/whoami ; /usr/bin/php /home/xxx/domains/yyy.com/public_html/mailtest.php'

but gets the email returned as undeliverable with error:

             The mail system

<forsms-yyy,com@ourhosting.com> (expanded from <forsms@yyy.com>):
   Command died with status 1: "/bin/sh -c '/usr/bin/whoami ; /usr/bin/php
   /home/xxx/domains/yyy.com/public_html/mailtest.php'". Command
   output: nobody Could not open input file:
   /home/xxx/domains/yyy.com/public_html/mailtest.php

We see in whoami that it's user "nobody" that is executing tries accessing the php file. But it doesn't execute.

When I copy the php script file into /home at root and put this command:

/bin/sh -c '/usr/bin/php /home/mailtest.php'

then the script executes and the mail doesn't get returned.

"nobody" has group nogroup to which no linux user belongs too.

This feature, accessible by all virtualmin domain-administration users is a problem, as it doesn't execute as the user himself, like cron jobs do.

Status: 
Closed (fixed)

Comments

Submitted by andreychek on Tue, 02/05/2013 - 09:07

Howdy -- I'll let Jamie comment on whether that's intentional... but the nobody user and nogroup group should actually each be fairly safe. Users shouldn't belong to nogroup, by default, and that's designed to be a safe fallback group to use.

We can double-check to make sure that's the case on your system though... what output do you see when running this command:

grep nogroup /etc/group

Submitted by beat on Tue, 02/05/2013 - 09:15

# grep nogroup /etc/group
nogroup:x:65534:

Ok, so no members in that group :-) , which explains why the user couldn't run his script on emails to that alias.

I got confused by the "Edit group" layout of Webmin:

Members  All users                     Users in group
             (all users listed here)     (none here)

So NOT a vulnerability. Ticket can then be made not-private. :-)

But executing as "nobody" instead of the user's userid makes that mail alias function "feed to program" of little use to normal users ;-)

Submitted by JamieCameron on Tue, 02/05/2013 - 12:50

This is unfortunately expected and un-avoidable - when you create an alias like that, the command is run by the mail server (Postfix) which doesn't have permissions to run scripts as other users.

One work-around would be to have the mail go to a Virtualmin user who had a procmail rule setup to run whatever command you want, which will run with the user's privileges.

Submitted by beat on Fri, 02/15/2013 - 03:05

Thanks for the replies! I'm closing this ticket.

Hope it's public so that people googling for information can find it.