Permissions set incorrectly in plugin archives

[Cerulean]

When installing GetSimple and plugins I like to upload the files in their original zip archives and extract them on the server using my host's file manager because it's a big time saver versus FTPing the extracted files individually.

This works fine with the main GetSimple archive, and files and folders get the correct 644 and 755 permissions respectively. However, I notice that plugin archives downloaded from the Extend Repository extract with the wrong file and folder permissions: everything gets 777 permissions, which my host and many other hosts wont tolerate.

My workaround for the plugins is to recursively set the file/folder permissions with my FTP client, then compress the files/folders to a new zip on the server, which I then download and use in place of the original zip for future installations as this archive extracts with the correct permissions.

I'm not clear on how these permission settings are actually stored for files/folders in a zip archive, but is it possible to make some change to the Extend Repository so archives automatically get the correct permissions?

[shawn_a]

Are you extracting on windows or unix?

[Cerulean]

It's a Unix server (CentOS Linux x86).

[shawn_a]

are you extracting them to the same location ?
afaik , zip files cannot store unix file perms. So i wonder if you are seeing different results between the 2 based on where you are extracting them.

have you tried umask, perhaps your file system is doing it, or perhaps the utility you are using attempts to preserve and convert them, in which case it might have a argument to disable that.

also remember that gs creates some of its folders, not all are in the zip.

[datiswous]

Certain plugins have wrong permissions set. For example all plugins made by mvlcek (that means a lot of important plugins) have 777 permissions set for files and folders (wonder how this can effect security). See here: http://get-simple.info/forums/showthread...permission (post 56,57,59,60).
And: http://get-simple.info/forums/showthread...permission (post 284,285)

Some other plugin developers have also different permissions set in their plugin files.

I always use Cpanel and afterwards I have to change all the permissions..

You are the second person (the other one is myself) I know who find this an issue..

[Cerulean]

afaik , zip files cannot store unix file perms.

I have no idea how they store the file permissions, but they do. This is proven by the fact that I can...

• set the correct permissions on the server
  
• compress the file/folders to a zip archive on the server
  
• download the zip
  
• upload the zip (even to a new GS installation)
  
• extract the zip
  

...and the file/folder permissions are correct.

all plugins made by mvlcek have 777 permissions set for files and folders

Yes, it's mvlcek's plugins that I get the permissions problems with. It's his plugins that I use most often (because apart from the permissions issue they're excellent). It seems he's not sure how to fix this permissions issue, and unfortunately I can't offer any suggestions apart from my workaround above. If I find out anything more I'll post back.

[hameau]

Hello,

I feel your pain!

While the original zip didn't support permissions, InfoZIP does and InfoZIP is the basis for many (most? all?) modern implementations of zip. I suspect that the origin of mvlcek's permissions problems is from mixing Unix and NTFS filesystems.

My workarounds depend on how I want to deploy the plugin. For one-offs to my own hosting, I unzip locally and upload to the webspace. The hosting provider has masks that handle everything for me.

Alternatively, unzip, set appropriate permissions and zip again locally. The new archive can be uploaded and unzipped remotely.

If you have shell access to the webspace, these two lines are really handy, run in the plugins directory:

Code:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Adjust the permissions to suit your (hoster's) requirements.

I work exclusively on Linux: these solutions may not work on other platforms.

[shawn_a]

Perhaps you can umask first before extracting, or use cmd level extraction where you can override this behavior.