Prevent ASL (Atomic secure linux) from Crashing PHP
Forum
  1. Forums
  2. CloudLinux and Control Panels
  3. CloudLinux and cPanel
  1. Richard Hordern
  2. 13.12.2012
  3.  Subscribe via email
Hello,

On our pre production server we have been running automatic yum updates and last night ASL ( http://www.atomicorp.com/products/asl.html ) updated it self and decided it was a good idea to chmod apache log directory to 700 (originaly 755). This resulted in all fcgid PHP scripts not working any more.

I contacted their support about this issue and was told it was a known bug but was given the impression that it was a low priority bug (that they have known about for at least 9 months).

Fr om what I have understood they don\'t think it as important as it only affects hosts running mod_fcgid.

I asked them for a solution, and the solution they gave me was to change the chmod back whenever I noticed that all PHP scripts on the server had stopped working.

I see three solutions to get around this problem :

1) Always run yum update manually and check that PHP is running after each update
2) Add a chmod command to cPanel\'s post update script
3) Move the location wh ere fgcid creates it\'s sockets

The first solution is a pain because important security updates won\'t always be run in a timely manner.
The second solution seems a bit of an overkill, but should prevent PHP scripts going down for a long period
The third solution is my prefered one but I\'m not sure what this would imply exactly and I presume that it\'s not supported at all by cPanel.

I would be interested to find out if you have run into this problem, if so what work around you have applied to get around this bug, and would be greatfull for any reccomendations (I don\'t think I will get any from their support).

I\'m posting this issue on CloudLinux\'s forums because on ASL\'s forums no support has been given and because I\'ve found that CloudLinux has always provided excelent support even with problems that are not directly to do with their software.
Rate this post:
  1. 13.12.2012 17:12:43
  2. # 1
Igor Seletskiy Accepted Answer
Posts: 1201
Joined: 09.02.2010
0
Votes
Undo
Richard,

I would recommend going with #3, and putting fcgid.sock into /var/run/httpd (just make sure directory exists). I don't think cPanel will have an issue with that.

The directive to do that will be either:
FcgidIPCDir
or 
SocketPath (i think that is the one apache users).

On cPanel server it is usually defined as logs/fcgid.sock, change that to /var/run/httpd/fcgid.sock
Also, not sure if it is defined in httpd.conf -- but if it does -- don't forget to run apache config distiller.
  1. 14.12.2012 12:12:46
  2. # 2
Richard Hordern Accepted Answer
Posts: 219
Joined: 19.03.2011
0
Votes
Undo
Thanks Igor

I created /var/run/httpd and added to my pre virtualhost include 

FcgidIPCDir /var/run/httpd/fcgid.sock

I then ran chmod 700 /usr/local/apache/logs/

And PHP are still running !

This will prevent issues with ASL setting the chmod of /usr/local/apache/logs to 700, but shoud it be 755 or 700 ?

Would apache or PHP ever need to be able to read or execute inside /usr/local/apache/logs once the sockets are moved elsewhere ?

To I need to add this location to cagefs or run 

cagefsctl --update

?
  1. 14.12.2012 21:12:33
  2. # 3
Igor Seletskiy Accepted Answer
Posts: 1201
Joined: 09.02.2010
0
Votes
Undo
It should be 700 for logs directory (no point for anyone else even to be able to chdir or read it)
PHP should never need to read log files. It wasn\'t PHP itself, but mod_fcgid (running as apache) that needed to chdir to that directory.

And it takes effect before cagefs, so nothing needs to be done on CageFS side.
  1. 15.12.2012 06:12:45
  2. # 4
Richard Hordern Accepted Answer
Posts: 219
Joined: 19.03.2011
0
Votes
Undo
Thanks Igor,

When I put this directory in 700 I get the following errors :


[Sat Dec 15 12:45:01 2012] [error] [client 127.0.0.1] (13)Permission denied: Cannot open SSLSessionCache DBM file `/usr/local/apache/logs/ssl_scache\' for status retrival


I\'ve put the chmod back to 755 in the mean time.
  1. 15.12.2012 11:12:30
  2. # 5
Igor Seletskiy Accepted Answer
Posts: 1201
Joined: 09.02.2010
0
Votes
Undo
I never had to deal with SSLSessionCache, but you can probably move it to the same location as fcgid.sock
  1. 16.12.2012 05:12:17
  2. # 6
Richard Hordern Accepted Answer
Posts: 219
Joined: 19.03.2011
0
Votes
Undo
I tried to change SSLSessionCache, I redistilled the httpd.conf but the setting was lost when I rebuilt the httpd conf file to see if the distill worked.

I guess cPanel doesn't was us changing locations like this.

I see multiple values that would need to be changed if apache logs are set to 700 :



RewriteLock /usr/local/apache/logs/rewrite_lock
SSLSessionCache         dbm:/usr/local/apache/logs/ssl_scache
SSLMutex  file:/usr/local/apache/logs/ssl_mutex


Also I'm thinking about moving fcgid sockets to another location as /var is on hard disks and /usr is on SSD's so I guess it's better if the sockets are created faster then slower…
  1. 16.12.2012 06:12:20
  2. # 7
Richard Hordern Accepted Answer
Posts: 219
Joined: 19.03.2011
0
Votes
Undo
As ASL say that they are working on a fix to this issue and that the upgrades won't be very often I've decided to do this :

I edited /scripts/postupcp

I added the following line :

/bin/chmod -v go+rx /usr/local/apache/logs #Fix ASL chmod issue

I believe chmod doesn't touch the file if the chmod's are correct.

This is not a permanent solution as if ASL changes the chmod's sites will go down until /scripts/postupcp is run.
/scripts/postupcp is only run once the cPanel update has completed, this will take between 2 and 20 minutes depending on the updates performed (just timed an /scripts/upcp without any updates : 2minutes).
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.