suPHP Problem

[DanEZPZ]

Hi,

I've just switched one of our servers from Apache to Litespeed and have encountered a problem with suPHP.

Previously if a client were to chmod a file or directory to 777, Apache would deny access and return a 500 error. Apache was also denied access if the file or directory was chowned to another user.

Litespeed seems to have access to anything, either chmod 777 or chowned to another user.

Is there any way of fixing this problem?

Thanks,

Dan

 

[MikeDVB]

I as well am curious about this - mostly the permissions part. Is there a way to enable checking of permissions on files/folders and then not display/execute them if they are set higher than 755 as there was with suPHP with Apache?

If there is... I'm not seeing it.

 

[MikeDVB]

I've found this:

But I'm not sure where to find information on how to set the settings and from what I understand it does not apply to PHP but just static files?

 

[MikeDVB]

I know that the requirement of no higher than 755 was a setting in suphp.conf when running Apache with suPHP - and wasn't something imposed by Apache itself.

I know you could turn off those settings, and I would think with php_open_basedir on you would be safe but I've personally never allowed 777 so I hadn't looked into it much.

 

[MikeDVB]

I'd really just like an explanation of the settings in my previously posted image

 

[mistwang]

Right now, LSWS just follow linux file system permission, not act like suphp which block script with permission mask 777. LSWS uses open_basedir instead. However, it is nice to have feature, so we will add it to our to-do list.

Yes, those permission settings posted in the image is for static files, found it cause more trouble than what it helps, so we turn it off by default. It probably is a good idea to have similar check for scripts running in suEXEC mode.

 

[MikeDVB]

The thing is that even on a server running suPHP if you run a find for files with 777 permissions you will find a lot (images, .html pages, etc...) it would just be nice to not allow executable files to be modified by the public/group just in case

Anyways, it is nice to know that you do take what your users would like to see into mind.