[Case 80437] cPanel 11.38 breaks email pipes on shared servers

[Eric!]

My host provider recently upgraded to 11.38.2 and my advanced email pipe to a PHP script immediately started to fail:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pipe to |/home/user/public_html/email_proc.php
    generated by [email protected]

The following text was generated during the delivery attempt:

------ pipe to |/home/user/public_html/email_proc.php
       generated by [email protected] ------

2013-12-24 10:36:27 [6] Cannot open main log file "/var/log/exim_mainlog": Read-only file system: euid=0 egid=32007
2013-12-24 10:36:27 [6] cwd=/home/user/public_html/ 5 args: /usr/sbin/sendmail -t -i -f [email protected]
2013-12-24 10:36:27 [6] Cannot open main log file "/var/log/exim_mainlog": Read-only file system: euid=0 egid=32007
exim: could not open panic log - aborting: see message(s) above

I understand this is probably due to the new Jail System Update.

Is there anyway around this? I understand that EXIM is supposed to run inside the user's VirtFS:

When a user's shell is configured to jailshell or noshell, Exim runs any process created from alias or filter files inside of VirtFS. This action provides extra security because Exim commands will run in a jailed shell and not affect other users

So if Exim does need to write something shouldn't there be a place in the user's file system for this? Right now my host provider is just saying tough luck, you can use pipes anymore on a shared host and sent me a list of other providers.

I could write a cron job to access the mailbox via IMAP and process messages, but that seems like a real waste of power instead of being able to do it on demand.

Thanks in advance for the help.

 

[Eric!]

Re: cPanel 11.38 breaks email pipes on shared servers with noshell -- exim read only filesystem erro

Through my testing I've also found that CRON jobs that call php scripts which use mail() generate the same issues as the mail service when it pipes to the script.

2013-12-25 22:39:01 [4] Cannot open main log file "/var/log/exim_mainlog": Read-only file system: euid=0 egid=32007
2013-12-25 22:39:01 [4] cwd=/home/user/public_html/file 3 args: /usr/sbin/sendmail -t -i
2013-12-25 22:39:01 [4] Cannot open main log file "/var/log/exim_mainlog": Read-only file system: euid=0 egid=32007
exim: could not open panic log - aborting: see message(s) above

It would seem that anything that is called via cron or perhaps piped via exec() like from the mail service is not setup to access the VirtFS and is using the common files which are now mounted as read only on a shared host.

Interesting is that anything called via Apache doesn't seem to run into this VirtFS access problem. Is this because Apache is normally setup to spool to the VirtFS?

Any ideas on what is wrong with my host service?

 

[cPanelMichael]

Hello

This is related to internal case number 80437. A resolution for this issue is included with cPanel as of version 11.40.1.0. You may want to consult with your hosting provider to see if they are able to update cPanel to a tier that uses a version of cPanel with this fix included.

Per the Change Log:

Fixed case 80437: Fix jailshell recursive mount readonly fs problem.

Thank you.

 

[Eric!]

Fixed case 80437: Fix jailshell recursive mount readonly fs problem.

Wow, thank you! I thought I was taking crazy pills.

I did see this in 11.40.1.4:

Fixed case 84393: Mount directories rw so mailman can function under jail.

Would this also prevent exim from running jailed (see problem outlined in first post)?

 

[cPanelMichael]

No, it does not alter the jailed environment for Exim. However, I mentioned this case specifically because it should resolve the error messages you were reporting in your first post. Per the internal case, here is what was happening:

If a filesystem designated as a read/write virtfs mount existed on the system as a separate filesystem, it would also be treated as a recursive mount causing it to inherit the parent filesystem's ro or rw status without regard for the mount flags specified for the filesystem in question.

Thank you.