PHP - rmdir (permission denied) - php

I have an easy script to create and delete a folder, but when I try to delete a folder, it brings up and error.
The code:
<?php
if ($_POST['hidden']) {
$key = "../g_test/uploads";
$new_folder = $_POST['nazevS'];
$new_dir_path = $key."/".$new_folder;
$dir = mkdir($new_dir_path);
if($dir)
chmod ($new_dir_path, 0777);
}
if ($_POST['hiddenSS']) {
$key = "../g_test/uploads";
$new_folder = $_POST['nazevS'];
rmdir($key."/".$new_folder);
}
?>
The error msg:
Warning: rmdir(../g_test/uploads/) [function.rmdir]: Permission denied in /home/free/howto.cz/m/mousemys/root/www/g_test/upload.php on line 51
Does anyone know how to delete the folder (hopefuly with everything inside) ?
Also if you see any other improvments, the code could have, feel free to tell me. :-)
Thanks, Mike.

Generally speaking PHP scripts on Unix/Linux run as user "nobody", meaning they need the "all" privileges so it's a permissions problem with the directory. Also, to delete a file or directory in Linux/Unix you need write privileges on the parent directory. That might be your problem.
If you have problems with the files or directories you create, use chmod() on them to set the right permissions.
Also it might not be empty.
Also, it's worth mentioning that
$new_folder = $_POST['nazevS'];
$new_dir_path = $key."/".$new_folder;
is really bad from a security point of view. Sanitize that input.

For the purpose of this answer, I will put the security risks of allowing any and all uploads in a directory aside. I know it's not secure, but I feel this issue is outside the scope of the original question.
As everybody said, it can be a permission problem. But since you've created the directory in your code (which is most likely running as the same user when deleted). It doubt it is that.
To delete a directory, you need to make sure that:
You have proper permissions (as everyone pointed out).
All directory handles must be closed prior to deletion.
(leaving handles open can cause Permission denied errors)
The directory must be empty. rmdir() only deletes the directory, not the files inside. So it can't do its job if there is still stuff inside.
To fix number 2, it is extremely simple. If you are using something like this:
$hd = opendir($mydir);
Close your handle prior to deletion:
closedir($hd);
For number 3, what you want to do is called a recursive delete. You can use the following function to achieve this:
function force_rmdir($path) {
if (!file_exists($path)) return false;
if (is_file($path) || is_link($path)) {
return unlink($path);
}
if (is_dir($path)) {
$path = rtrim($path, DIR_SEPARATOR) . DIR_SEPARATOR;
$result = true;
$dir = new DirectoryIterator($path);
foreach ($dir as $file) {
if (!$file->isDot()) {
$result &= force_rmdir($path . $file->getFilename(), false, $sizeErased);
}
}
$result &= rmdir($path);
return $result;
}
}

It looks like you need access rights on the folder you're trying to edit.
To change this:
chmod ug+rw /home/free/howto.cz/m/mousemys/root/www/g_test/
or maybe you'll need to do
sudo chmod ug+rw /home/free/howto.cz/m/mousemys/root/www/g_test/
Make sure that this is what you want to do and that your application is secure. Don't give write rights to any application since it could lead to security issues.

The webserver requires write access to the folder you're trying to delete. You can provide this with:
chgrp -R www-data g_test/uploads
chmod g+w g_test/uploads
where www-data is the user that the webserver runs under (may be apache or some variation depending on your OS and server installation). After this you can run rmdir (or rm -r if the directory isn't empty).
Also, keep in mind that giving the web server the ability to write to a directory posses security problems. In certain situations, this could allow a malicious user to run arbitrary code (i.e. take over your machine), or modify your website (i.e. server spyware).
For these reasons, you should only give dirs write perms that:
absolutely need them
don't contain source code
are outside the dir containing scripts
owned by the server
In this setup on a production machine, you could set up a separate directory just for this type of file, that only Apache can write to. If you have to deploy files to this directory, use sudo or the root account to do so to limit the accounts that have access.
For a more complete description of what I mean, have a look at the security tips section in the Apache documentation.

Related

MKDIR doesn't work correctly

For some reason all folders created dynamically using my PHP upload script get permission 1354 and then it's not possible to save files inside them.
if(!file_exists($options['uploadDir']) && !is_dir($options['uploadDir'])
&& mkdir($options['uploadDir'], 0750, true))
{
$this->data['hasWarnings'] = true;
$this->data['warnings'] = "A new directory was created in " .
realpath($options['uploadDir']);
}
if(!is_writable($options['uploadDir']))
#chmod($options['uploadDir'], 0750);
I don't know what am I doing wrong.
Check parameters of your http server especially the profile of the user running it and the default user profile of the system. There may be a "umask" set somewhere forcing another permission.
You can try to change the umask with a php command umask.
Also you can check the permission of the parent folders and also check the ownership of your folder.

Create directory in php avoiding 777 permission

I have a php script that is used to create different directories for different users to store their images.
One way to do this is use 777 permision like this:
$path = 'images/product/'.$pid;
if( ! file_exists($path)) {
$mask=umask(0);
mkdir($path, 0777);
umask($mask);
}
Is there any other alternative that doesn't involve to use 777 permision for the directory, for example to set the file owner and group?
Changing the file owner/group requires privileges that your Apache should not have if you want to run it safely.
However, you don't necessarily need 0777. I guess you are storing images, so you can use 0644!
Side note: chgrp() and chown() are the 2 functions giving you the ability to change file group/owner

folders created with php, are being owned by apache

We are using a linux dedicated server in our company.
Whenever we create a folder with php script, apache is owning the folder and each time I have to connect to server via root in order to change the owner to the user and the permissions
But I don't know which setting I should change in order to fix this.
I tried to switch the safe mode on/off but it didn't work.
I'd be glad if someone could help me
Thanks in advance
Have you tried using the chown PHP command and chmod PHP command?
There are 2 ways to do this:
chown() where you can change the file permissions via executing that function.
or if you are able to move files around using an FTP, you can drag the file outside of the document root (public_html/), and right click -> change file permissions on the file.
CHMODs are what you want to be looking at. 777 will give anyone and everything access to your file, which you can use as a test to make sure you have file permissions. I don't recommend keeping the permissions on 777 at all though.
This is a portability issue and depends on your server configuration (i.e. mod_php or FCGI with SuExec).
You can try using the chown function right after you created the file, but that will only work if you know who the actual owner should be (which is not always the case). To overcome this issue, I wrote a simple method that tries to find the best possible file mode that always assures reading and writing (as well as execution for directories) without giving excessive permissions:
function xChmod($path, $chmod = null) // adapted from phunction
{
if (file_exists($path) === true)
{
if (is_null($chmod) === true)
{
$chmod = (is_dir($path) === true) ? 777 : 666;
if (extension_loaded('posix') === true)
{
$user = posix_getpwuid(posix_getuid());
if (array_key_exists('name', $user) === true)
{
$chmod -= (in_array($user['name'], explode('|', 'apache|httpd|nobody|system|webdaemon|www|www-data')) === true) ? 0 : 22;
}
}
}
return chmod($path, octdec(intval($chmod)));
}
return false;
}
Basically, if you omit the second $chmod argument, it will use 0777 for folders and 0666 for files by default, however, if PHP is being run under a non-standard user, it will decrement the mode by 22, yielding 0755 for folders and 0644 for files. Bare in mind that this will only work for files that already exist, so if you're creating a directory you'll need to have additional precautions.

Move a file and rename it

Figured PHP's rename would be my best bet. I didn't see many examples on how to use relative URLs in it though, so I kind of compromised. Either way, this give me permission denied:
I want to do this:
$file = "../data.csv";
rename("$file", "../history/newname.csv");
Where ../ of course would go back 1 directory from where the script is being ran. I couldn't figure out a way...so I did this instead:
$file = "data.csv";
$path = dirname(realpath("../".$file));
rename("$path/$file", "$path/history/newname.csv");
However I am getting permission denied (yes the history folder is owned by www-data, and yes data.csv is owned by www-data). I thought it was weird so I tried a simple test:
rename( 'tempfile.txt', 'tempfile2.txt' );
and I made sure www-data had full control over tempfile.txt...still got permission denied. Why? does the file your renaming it to have to exist? can you not rename like linux's mv? So I instead just copy() and unlink()?
In order to move a file from "../" to "../history/", a process needs write permission to both "../" and "../history/".
In your example, you're obviously lacking write permission to "../". Permissions for the file being moved are not relevant, by the way.
Not only ownership plays a role, but also file permissions. Make sure that the permissions are set up correctly on the source file and destination directory (e.g. chmod 644 data.csv).
Is www-data the same user as Apache?
Edit: Take care to provide existing, absolute paths to realpath(). Also beware of the following:
$path = dirname(realpath("../".$file));
This might yield nothing, because the file ../data.csv might not exist. I.e., the result of realpath() on a non-existent file is false.
Here's some code that might work better for you:
$file = "data.csv";
$path1 = realpath($file);
$path2 = realpath(dirname($file).'/..').'/history/newname.csv';
rename($path1, $path2);
You should be extremely careful that $file cannot be edited by the visitor, because he could change a request manipulate which file is renamed to where.

Recognizing the root dir in PHP

I'm writing a PHP function that will delete all the files in the directory that's passed to it (and eventually, possibly expand it to a recursive delete). To be safe, I want to make sure that, through a bug or something, I don't try to delete anything if the directory passed in is the root directory.
File permissions should protect me to a large extent, but just in case, and especially if I expand it to a recursive delete I just want to take that extra step.
As a complicating factor, this code may be run in a windows machine or a linux machine, so the root directory may look like 'C:\' or '/'. I assume there are other ways that really refer to the root as well, possibly 'c:\temp..'
So, is there a reliable way in PHP to recognize that a dir spec resolves to the root of the file system?
Elaboration...
I'm writing PHPUnit tests for a web app and I'm trying to create a framework where the state of the app is backed up before the tests are run and restored afterwards. The app allows users to upload files. Depending on what the file is it is copied to one of several possible directories.
To save and restore the state of the app those directories need to be copied somewhere, the tests run, then the directories need to have their files deleted and retreived from the backup.
The location of these directories can vary from one machine to another and I know that some people put them outside of the web app. There is a configuration file that can be read by the test that gives the location of those directories for the given machine.
If I don't restrict all these directories to a specific dir tree it's difficult to do the jailing. If I do restrict these directories to a specific dir tree then some people will have to reconfigure their machines.
You should have a defined root folder, which you never go above, a.k.a. jailing. The root folder is not the only folder where severe damage can be done.
Edit.
Although I still advocate using some sort of jailing, I suppose you could recognize the root folder by stripping out any drive-letters and translating \ to /. The root folder would then always be a single /.
function isRootFolder($dirpath) {
list($drive, $path) = explode(':', str_replace('\\', '/', $dirpath), 2);
return $path == '/';
}
Try, this function:
function is_root_dir($path)
{
$clean_path = realpath($path);
if($clean_path == '/' || preg_match('/[a-z]:\\/i', $clean_path))
{
return true;
}
else
{
return false;
}
}
It's not tested, I just wrote it in the editor here. realpath() resolves the path, folowing simbolic links and resolving stuff like: c:\temp.. == c:\
Edit: In the end you should folow the advice that nikc gave you, define a list of directories that are safe to delete.
I use this:
if (dirname($target)==$target) { // you're at the root dir
(is portable between Microsoft and everything else)
C.

Categories