Edit Folder Permissions Reverting

[kaliatech]

First, if you are a user getting errors on upload due to "Permission Denied" errors see this:
http://forum.coppermine-gallery.net/index.php?topic=13654.msg63036#msg63036

I had this problem as well, and after setting the edit folder permissions manually, my uploads again worked for a while.  However, invariably something will happen and my edit folder owner/group and permissions will revert back to something incorrect.   When this happens, users can again no longer upload until I manually fix the permissions.

I believe this to be a common problem among Coppermine users, although many users probably don't realize it.  I see A LOT of posts in these forums (and others such as PHPNuke)  related to this...and while the initial fix seems easy, if it is automatically reverting back at some delayed time interval many people will get confused and think the original fix didn't work.

I'm writing this to the mods in this forum...who seem a little bitter about the constantly asked same issues.  I hope this has not been brought up before, but based on this recent post by a mod:

However, I would like to know why my edit folder got messed up...

We would like to know the reason as well. Never happened to me, on many coppermine installs. Must be something that coppermine users do that coppermine developers never do - we simply can't replicate, although it seems to happen quite often. Anyone who finds out what the reason is is welcome to post.

...I assume it hasn't.

I am not a PHP or Coppermine expert, but my assumption is that the underlying problem is related to the /edit folder being periodically deleted and re-created automatically by coppermine.  When a new folder is created by Coppermine under certain PHP/Apache virtual host configurations, it gets created with a default PHP/Apache user/group rather than the virtual host user group that is used by all other script access.  As such, the owner/group is incorrect...and possibly this also causes the permissions to be incorrect.

I have noticed references to a clean-up/garbage collect routine in the coppermine scripts, although I haven't been able to locate the exact source where the /edit folder is deleted yet.

Because many users (including the mods/devs) do not have this problem, it must be server configuration related. However, antedotely, I think it may be becoming more and more common.  My configuration:

- RedHat Fedora Core 2 Variant
- Apache 2.0.50
- PHP 4.3.10
- Using Plesk 7.1.6 Control Panel (Plesk has a special suexec and I think makes some changes to how the apache user works in regards to virtual hosts. May or may not be related.)

I would think at a high-level the possible fixes are:
1)  Somehow modify server configuration so that new folders have the correct owner/permissions when running in virtual hosts.       
2) Modify coppermine to automatically set the correct owner/permission after creating a new edit folder.
3) Modify coppermine (or?) so that the manually configured edit folder never gets deleted/reset.

I think the second two options would preferred by most users using an Internet host. Kudos to the devs for building a great gallery system. I think more people would use Coppermine if the various permissions related problems could be simplified/fixed though.

- Josh

[Nibbler]

The issue is over ownership of the directory, yes.

The edit directory is not deleted, it is moved and renamed. It becomes something like ~0. in one of your album directories, but the cause is unknown. There is a fix in place that stops it being moved in the stable branch:

in upload.php find

Code Select Expand

        // Form path to temporary image.
        $path_to_image = "./{$CONFIG['fullpath']}edit/".$file_set[1];


and add below it

Code Select Expand


// prevent moving the edit directory...
if (is_dir($path_to_image)) cpg_die(CRITICAL_ERROR, $lang_upload_php['failure'] . " - '$path_to_image'", __FILE__, __LINE__, true);

It doesn't solve the initial problem, but see if it helps.

[kaliatech]

I am using CPG 1.3.2 dated 08/14/2004.  With that version, the exact code you listed isn't in the upload.php.  I'm assuming you meant this line instead:  (Line 2223 in upload.php)

Code Select Expand


        // Form path to temporary image.
        $path_to_image = './albums/edit/'.$file_set[1];


I added the line you indicated immediately below this.  I guesses this causes it to die if the expected image name is actually the /edit directory (or an existing file) ...and the reason that happens is currently undetermined? 

I will try to post back in a week or so the result.  (It usually takes a while for the problem to occur again for me....I'm not sure what the trigger is? If you do, post and I'll try it immediately.)

Thanks for your reply.

(Also, are you saying that the stable branch in CVS fixes this? ...and is that being referred to as the 1.4 alpha?)

[Nibbler]

The stable branch is 1.3 with all known fixes applied, and includes some minor fixes that aren't enough to warrant an actual release (that's why my code is a little different to your code). Though you'll need to copy the english.php from the package over the stable cvs version of english.php at the moment if you use the stable checkout. The fix causes a coppermine error message if it attempts to move something which is really a directory.

1.4 is in the devel branch.