Cannot remove directory from media database

[Thomas]

Hi,

today I recognized that I'm not able to remove a directory from the media database. It was actually created with the managing tool so the userid/groupid should be ok. But when trying to remove it an error is given that there is no write access to that directory.
I checked this it, the properties of that directory is '777'.

Regards, Thomas

P.S.: Is it a good idea to implement the CVS tree into a live site?

[garvinhicking]

Hi Thomas!

Can you give some more information? What is the exact path location? Does it contain subdirectories? Is it below the root of the upload folder, or within other subfolders? Are there any files in the directory? Did you check the permissions of those files?

Does your server have safe_mode on? CGI or Module PHP?

About the CVS tree - this is usually no problem, because no sensitive data is contained therein...

[Thomas]

Hi,

What is the exact path location?

/home/www/web106/html/ is the path to the website directory. s9y is installed in the root directory (in Apache terms DOCUMENT_ROOT for my domain). So the uploads directory is /home/www/web106/html/uploads/.
The directory I'm speaking about has the name '0904' (without quotes). The absolute path information is /home/www/web106/html/uploads/0904/ and does not contain any subdirectory or image in it.
The permission of the directory '0904' is 777. safe_mode is set to off. The owner is the user under which the webserver runs (wwwrun/www). Because my user is something else I'm not even able to remove it via FTP nor via my Confixx panel (which executes the scripts under my userid/groupid).

HTH, regards, Thomas

[garvinhicking]

Well, there seems to be something quite wrong - because if the permissions are '777', *Every* user would be able to delete that file.

Including your FTP user. So I suppose there are some files left in the directory? Did you check for hidden files, beginning with '.'?

Regards,
Garvin.

[Thomas]

Well, the owner of the directory (not file) is the wwwrun user under which the webserver runs. The FTP user differs in that case and is my own user and so is not able to delete the directory because he's not the owner.
So a script running started through the usual browser should be able to delete the directory - which is not the case here within s9y.

I checked the directory with a ftp client. Actually there's no file inside the directory, even no '.*' file (except if there's something else created by s9y created with a starting '.').
In the media db administration I could also mark to delete files outside the dir which means in my understanding that the script tries to remove the dir recursivly.

Regards, Thomas

[garvinhicking]

Hi Thomas!

For security reasons, s9y does not offer a recursive deletion; the checkbox only tells that if you uploaded files via FTP, s9y tries to delete them as well.

So, to get it all together:
/home/www/web106/html/uploads/0904/ is the directory you want to remove. There are no files and no subdirectories for that. The 0904 directory is 777. This should mean, that *any* user is allowed to remove the directory and files therein, no matter if its owned by nobody, wwwrun or ftponly...

Regards,
Garvin.

[Thomas]

Hi,

sorry, but if you're not an owner of a directory you're not allowed to remove it as any other user except root. Another exception might be that if you're sitting in front of a console or are logged in via telnet.
I do not have the possibiliy, I only can use the Confixx panel or FTP. And possibly some scripts which finally run again under the apache's user.

Actually I created a file to remove the file with following code:

Code: Select all

<?php

$dir = 'uploads/0904';

if ( rmdir ( $dir ) ) {
echo "Success<br />\n";
} else {
echo "Error!<br />\n";
}

?>

And the directory was removed.

Regards, Thomas

[Thomas]

Hi,

had some time and investigated the code.

Truly the error is in the file serendipty_admin_images.inc.php.

Take a look at line 196-213:

Code: Select all

                case 'delete':
                    $path = $serendipity['serendipityPath'] . $new_dir;
                    if (is_dir($path)) {
                        if (!is_writable($serendipity['serendipityPath'])) {
                            printf(DIRECTORY_WRITE_ERROR, $new_dir);
                        } else {
                            // Directory exists and is writable. Now dive within subdirectories and kill 'em all.
                            serendipity_killPath(
                              $serendipity['serendipityPath'] . $serendipity['uploadPath'],
                              $serendipity['POST']['newDirectoryName'],
                              (isset($serendipity['POST']['forceDelete']) ? true : false)
                            );
                        }
                    } else {
                        printf(ERROR_NO_DIRECTORY, $new_dir);
                    }
                    echo '<br /><hr />';
                    break;

In line 198 you're testing if $newdir is a directory. In line 199 you're testing if $serendipity['serendipityPath'] is writeable. And if not you're generating an error saying that $newdir is not writeable. This doesn't make sense actually.

$newdir is a combination of $serendipity['serendipityPath'] + $serendipity['uploadPath'] + $serendipity['POST']['newDirectoryName'];

I'd rather suggest to test $serendipity['serendipityPath'] + $serendipity['uploadPath'] if it is writeable since the upper directory should be writeable to the user as well if he wants to remove a subdirectory.
So the change could be (in line 199):

Code: Select all

if (!is_writable($serendipity['serendipityPath'].$serendipity['uploadPath'])) {

For the media database is doesn't matter if the serendipityPath is writeable or not.

This are just my 5 Eurocents for this problem. I hope someone is watching that too.

Regards, Thomas

Edited 2 minutes afterwards
it is enough when changing $serendipity['serendipityPath'] to $serendipity['uploadPath'].
Tried that and it worked as well.

P.S.: You guys must have either a really huge practise writing the word 'serendipity' or you're all men of steel ...

[garvinhicking]

Hi Thomas!

Thanks a lot for looking so deeply into that! I have committed your changes to our CVS, and of course your changes were right. Sorry for not spotting the real problem earlier!

Best regards,
A Man Of Steel.

[Thomas]

No problem as long I can make myself visible to the world.