I was recently troubled by an injected spam script called alias.php. I’m still trying to work out how it got there, so I’m looking at directory permissions.
The parent directory of the offending file has the following permissions:
drwsrws---. 5 apache [group]
where [group] is the name of my group.
I don’t know whether weak directory permissions are the culprit, but, just in case, is there a more correct setup?
I’m running CENTOS 6.
Thanks
I'd suggest you removing group permissions to write on the directory
drwsr-s---
To detect the culprit - check the owner of the file (I'm no CENTOS user, don't know the command) see if it's the root or a group member.
If it's the root, someone has hacked you (I doubt it, though) and you have big issues to resolve
If it's a group member then the above solution is for you, unless you need to add or modify the directory's files in the future
I hope I was useful.
Related
I'm very new to Yii, so please bear with me. I've an existing XAMPP setup on my MacBook, and an existing project I need to take a look at. At first the project was looking for a yii.php, so I downloaded the appropriate version (1.1.17), and extracted that to /htdocs/.
I renamed it to yii, and set the yii directory in my index.php to:
$yii=dirname(__FILE__).'/../../yii/framework/yii.php';
For reference, the project has the following directory: htdocs/cdforum/web/index.php
With everything in place, or so I think, I started up XAMPP, and loaded http://localhost/cdforum/web/index.php only to encounter the following error:
throw new CException(Yii::t('yii','Application runtime path "{path}"
is not valid. Please make sure it is a directory writable by the Web
server process.'
I have seen some people get past this by setting the yii folder's ownership via chown to their own, or apache, but the first option didn't work for me, and apache apparently is an illegal user name.
Anything else I can try?
Change your username:group in httpd.conf file of Apache:
About line ~181-182:
To your user in your Mac.
Don't change the Apache User and Group. There are very good reasons why Apache has it's own user and group. Here's a simple example of what can go wrong...
While developing you make a mistake in your app and delete files
recursively in a directory, this directory has a sym link that you
follow into your home directory and you delete everything in your home
directory. This cannot happen if the users are different.
In production if you changed the owner of the user/group to a real user account the you'd almost certainly incur the wrath of the OPS department ie you're creating a security hole, a bad one.
The correct thing to do is to do what it asks ie make the directory writable by the apache process ie use chown or chmod. If you are developing then use this, in production this is also bad...
chmod 777 ./path/to/directory
In prod the directories apache need to write to would either have group write permissions for the apache user or be be owned by the apache user. Only those directories that it requires write access to, nothing else.
I have a project I need to generate all sorts of PDF documents for with PHP, so I searched and found TCPDF. All seemd OK until I got to saving files to some folder.
So, I created the needed folder, set 0777 permissions to it, then proceded with generating a file into it. The file was created and all looks good, but the file now belongs to the 'daemon' user, and has 0644 permissions.
I need the generated files to have 0777 permissions. I dont' mind the 'daemon' user as owner, but it would be cool to also know how to set it to the 'root' user.
I searched the official documentation to TCPDF for an answer, but failed to find one, so I came here to ask for help.
So, can anyone help me with some sugestions?
I have solved this problem in my Apache installations on Debian Server by setting the umask environment variable in /etc/apache/envvars.
In my case all I wanted was for the the user and group to have write permissions. I achieved this by setting the umask variable in that file to 007. The mask is applied to the permissions that are inherited by whatever user Apache is running under and so in my case the net result is that all files created by PHP within Apache have 660. I guess in your case you might need 000 (or 0000).
There is absolutely no point setting the execute permission and I would advise against it, because at best it achieves nothing and at worst it might introduce some strange security issue.
This answer contains more info on setting the umask: Setting the umask of the Apache user
The only benefit of this solution over PHP's chmod function is that you can "set it and forget it", the problem being that if you forget to set it then you have a problem.
I just changed to a production environment so I'm setting up everything, and I just bumped into a Permission Denied error (while using include())that I am pretty sure it is caused by the permissions. The thing is I have never used an actual server before, I have always use cPanel hosting, so I am no expert dealing with chmod and these things.
The folder containing all files I'll be include()ing has the following permissions drwxr-xr-x.
I'm pretty sure w stands for write, r for read and x for execute. But I have no Idea why does it have 3 columns (separated by '-') and how to change it using chmod. Any help will be appreciated.
solved, created a group and chowned and chmoded the folder to it.
I am writing a file upload using Zend_Form_Element_File(). I created a directory called users in the public directory. When I load the file, I got an error saying page is not found. I check the directory and saw that the permission is drwxr-xr-x. So I change the permission to drwxrw-rw- and load the page again. The page loads properly. But when I upload a file, it produces an error again. So I finally change the permission to drwxrwxrwx and everything runs properly.
My question is that am I doing the usual way that others are doing? I found it strange to make a directory executable.
Can someone explain whether I'm doing it correct? I am just learning Zend framework.
Directories must be executable if a program should be able to "enter" it. Entering a directory basically means accessing any file/directory below that directory.
Having "read" access to a folder allows you to list its contents - what "write" access does is pretty obvious.
However, for security reasons you should check if drwxrwx--- (770) is not sufficient; often your user and the webserver share a common group. If that's the case, there's no need to give any access to "world".
It would be even better to run your scripts as the same user as you - by using fastcgi that wouldn't be too hard, but if you are on shared hosting you usually do not have the necessary access to do this.
Typically when you set permissions on the directory it is so they cascade down to the files within via extended ACLS in the majority of cases. The issue that I see immediately is that you have granted world access which is a bad idea. The only user that needs permissions to the directory (700 at max) is going to be your web server. So I would revert security to be 700 asap.
PHP creates files with apache:apache ownership which seems to be causing issues with other php scripts accessing the file.
How can I allow php to create files with the same ownership as the files that created them?
I've read elsewhere that having safe_mode turned on can affect this but I've turned it off and reuploaded the files and i still get the same issue.
I'm sure this will be a simple question for someone more familiar with apache but I've failed to find the solution by searching around.
Thanks
If ownership matters and multiple users / projects are on the same server, you might want to look into SuExec in Apache: PHP files will then be run by the user indicated in the settings, so default ownership of files is automatically taken care of. It saves a lot of chown/chmod'ing, and the processes run by the user are more easily restricted.
Otherwise, I normally create a group with both the owner & apache, and set the default umask to 007.
If you are using a Windows OS you can start Apache as a service and allow apache to use your own account's permissions when starting.
Try using fileowner ( http://www.php.net/manual/en/function.fileowner.php ) to get the id of the owner of the current script, posix-getpwuid to get the username for that id ( http://www.php.net/manual/en/function.posix-getpwuid.php ) and chown ( http://php.net/manual/en/function.chown.php ) to set the user for the files.
Why go through all the programatic hassle to change the owner? apache.apache is a very insecure owner anyway. Why not just chmod 0777 the file providing read, write, and execute to all owners. This will eliminate the issue.
If you are still having troubles, then you may need to check if open_basedir is on. If that is the case, it is not file ownership or permissions, but location. This basically means you need to put the file in a location that apache/php already has included in their path.
A.M. mentioned chown() above, please be aware that generally chown() can only be used by root and your webserver running account is highly unlikely to be root, that's a very bad idea.
It is possible to setup sudo to allow chown by other users in specific areas and only to specific users. Just have to create a suitable entry in /etc/sudoers, usually by using the visudo program. If you do not have root access yourself, then your hosting provider will have to do this for you, if they will.
For more information: http://www.sudo.ws/sudo/sudo.html