I've just, tonight, upgraded from Plesk 9.5 to 10.3 in a fairly smooth way.

After tidying a few bits and pieces up, I noticed the following logs through ASL:



The UID 48 is apache and ASL seems to be preventing web-based forms to use the mail command to send emails.


This was working before the upgrade and I'm now stumped.

I have temporarily removed apache from the "untrusted" group to allow the forms to be used.


Can anyone offer any advice?

Thank you for the question. That message means the kernel has detected an application being run by an untrusted user that is not owned by root (perhaps Plesk changed the ownership). The second question is why is apache running postfix? That might be a bigger problem for you, maybe some malicious software is spamming people?

If its not malicious, the most secure option is make sure the application owned by root (and the parent directories it resides in) per the FAQ linked below. Making apache a trusted user is very insecure, and is not recommended. This would allow any software uploaded as apache, including malicious software, to be executable on the system, which is something you do not want. Files should be owned by actual users, not by special purpose users like apache. Thats a big hole if you leave it open.

Please see the FAQ for how to secure your application:

https://www.atomicorp.com/wiki/index.ph ... pplication

Hi Mike,

Sendmail is owned by root:



The scripts being blocked are legitimate and using phpmailer (http://phpmailer.worxware.com/) to generate HTML emails.

Before the upgrade, these worked fine and as-expected.


I definitely don't want to keep apache out of the "untrusted" group, but at this stage, it was the easiest and quickest way to restore service to multiple sites that use this sort of facility.


The class files for the phpmailer are all be owned by the FTP account of the vhost, but it still apache that is calling it.


None of the solutions in the linked wiki page seem to be completely suitable - but can you advise as to how the upgrade would have caused this? Or (now knowing more info) a way to get everything working the way it did?



Thanks

Have you checked the parent directories and the ownership of whatever script is calling it and what are their permissions?

I can't reproduce your case with a normally installed postfix, so maybe something you installed changed some parent directory permissions:

-bash-3.2$ uname -a
Linux asl-modsec-test.gotroot.com 2.6.32.43-6.art.x86_64 #1 SMP Thu Jul 14 14:14:48 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
-bash-3.2$ id
uid=48(apache) gid=48(apache) groups=48(apache),1005(untrusted)
-bash-3.2$ ls -al /usr/sbin/sendmail*
lrwxrwxrwx 1 root root 21 Sep 19 2010 /usr/sbin/sendmail -> /etc/alternatives/mta
-rwxr-xr-x 1 root root 201784 May 31 12:29 /usr/sbin/sendmail.postfix
-rwxr-sr-x 1 root smmsp 775064 Aug 11 13:24 /usr/sbin/sendmail.sendmail
-bash-3.2$ echo test | /usr/sbin/sendmail.postfix root@localhost
-bash-3.2$


One other thought, are you sure its phpmailer thats doing this? That message says it was a shell that did it, which implies interactive action is occurring. Is some other script calling sendmail.postfix? Or maybe a malicious user?



Do you mean a Plesk upgrade or something else? If you mean Plesk, you may want to ask Parallels what changed. you may also want to ask the phpmailer folks how their software works, because it looks very odd to me. I'm not sure this is the software being called, look carefully at the message:



That means /usr/sbin/sendmail.postfix was called by bash, a shell. Thats pretty strange for apache to call something via the shell. Are you sure your application is using an interactive shell? If it is, how does it do this? Thats a very odd way to call things from apache, normally I'd expect to see PHP, PERL or something else calling sendmail.postfix.

I'd try phpmailer myself, but I'm not familiar with phpmailer and it looks like its not a stand alone app but rather something you include in another app?

Thanks for the tips - after thinking about it, I remembered a method for phpmailer which is IsSendmail():

http://phpmailer.worxware.com/index.php?pg=methods

However it then does it, it calls sendmail directly, if that method is called in the setup.


I am currently grep-ing through all php files to check on how may occasions this code has been used across all domains to remove it and leave it to the default of using PHP's mail() method.


Once checked, I'll get apache back into the untrusted group and test.



Still no idea what's changed though - folder permissions/owners are all the same!

That seems to have worked - removing the IsSendmail() call and adding apache back into untrusted.


Thanks