File permission problems (UID:99)
Warning this information may be outdated. Please see the forum for up to date RevMax help and instructions. http://www.openxpayments.com.
It has come to my attention that some host seem a bit out dated and perhaps a bit unsecured as per files users and permissions. I am still researching it myself and looking for a solution that could possible fit all host. Until then if you encounter file permissions problems hopefully this will help.
Default installation php as mod_php module is one the biggest security hole at web servers software.
Lets consider why. If you have php installed as mod_php then all php applications are run under common user ‘nobody’ or ‘www’ or ‘apache’. It means if a user ‘smith’ has files located at his home directory, everyone else who has an account at the same server can read ( and modify ) his files using regular PHP-based filemanager.To avoid this problem apache provides ‘suexec’ technology to run users’ software under their own system accounts. It means user ‘smith’ has ‘my_secure_data.txt’ chowned to ‘smith’ and it will work because his applications are run under ‘smith’ system account at suexec enviroment. Basically, suexec technology is provided for applications running as cgi scripts.
On Non-suphp server environment, if a php script has to upload a file on a folder, (eg: OpenX plugins) in order to get it uploaded to the folder, it needs to have world writable permissions (777).
As plugins are uploaded by php,On Non-suphp server environment it is usually assigned user id of 99. This will make any php uploaded files to not be owned by the ftp user and unable to change permissions, or delete them.
THE PROBLEM: For convenience RevMax sets all directory (755) and file (644) permissions on install and may cause errors. You must however manually set permissions for the clients folder /openx/clients, after uploading.
You can test your server for this issue. If you can use phpinfo() you can create a php file with the following contents:
<? phpinfo(); ?>
Upload it to a web accessable folder on the server and browse to it in a browser, then look where it says Server API. If the value says Apache then its not running PHP using suPHP. If it says CGI then it is running suPHP.
If you know or can see this (uid:99) to be the issue, you can chown all the package folders and files, and chmod as needed. to restore functionality. Here’s some more info on “chown” and shell commands that may help.
If you know this before install you can uncompress the package and upload the files with ftp and set permissions accordingly, then log in to OpenX and install the plugin. You should then have ownership of all files and folders of the RevMax plugin. Plugin files and folders should be uploaded to the OpenX directory as seen in the unzipped package.
openx/clients….
openx/plugins/etc….
openx/www/admin/plugins…
To fix this problem permanently you may wish to follow this link and secure your server and install the suphp module for apache. This will of course make you go thru all of the plugins and reset file ownership and permissions as they are created on install with php and will cause errors as seen in openxmarket install on a cpanel server.
I am currently working on scripting to check for server variations, and hopefully fix this issue for these environments.
As always you can contact me directly or post to the forum if you have questions or need help.
Comments
Advertisement
