• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Fixed Exported add-on files have world-writable permissions

Affected version
XF2 DP 10

Liam W

Well-known member
#1
Is there a particular reason you make exported add-on files and directories have world writable status?

It doesn't seem right.

Liam
 

Chris D

XenForo developer
Staff member
#2
I don't think we're doing anything explicitly to cause this. Do you have a chmodWritableValue set in config.php?
 

Mike

XenForo developer
Staff member
#4
Just to clarify, which particular files are you talking about?

What is your PHP setup? More specifically, what user owns the files? What user does PHP run as?
 

Liam W

Well-known member
#5
Just to clarify, which particular files are you talking about?

What is your PHP setup? More specifically, what user owns the files? What user does PHP run as?
The files inside the built add-on zip.

PHP 7.1. It doesn't matter what user owns the files, it'll be the user that extracts it. PHP runs as my local account.

I did just realise that zip files aren't commonly known to support unix file permissions, but they do seem to be maintained when creating the zip on my Mac and extracting it on my centos server.

I just checked, and the files in the _build directory aren't writable, so it seems that it could be something your zip system is doing.

Liam
 

Chris D

XenForo developer
Staff member
#6
Well, the Zip system ultimately just uses ZipArchive behind the scenes so I'm not sure what it could be doing differently.

Can you perhaps try to be a bit clearer about exactly what you're doing to ascertain that the files contained within the Zip are world writable? Are you doing anything (like zipinfo or a specific archive GUI) to inspect the contents of the Zip file in place, for example?

We'll then be able to take a closer look.
 

Liam W

Well-known member
#7
Well, the Zip system ultimately just uses ZipArchive behind the scenes so I'm not sure what it could be doing differently.

Can you perhaps try to be a bit clearer about exactly what you're doing to ascertain that the files contained within the Zip are world writable? Are you doing anything (like zipinfo or a specific archive GUI) to inspect the contents of the Zip file in place, for example?

We'll then be able to take a closer look.
Just using the CLI.

Extracting them and listing the files.

unzip -Z also shows the permissions of the files inside (on both my Mac and my external server).

Liam
 

Snog

Well-known member
#8
I don't know for sure, but it sounds like something particular with your system. Checking the files created on my server shows there are no permissions stored in the zip file itself...

groupsperms.png

Checked a second file to be sure:
perms.png

However, when unzipped they do show as world everything...
ownerperms.png

I believe that's normal on a desktop system and the permissions change based on the FTP user when uploaded to a server.
 
Last edited:

Liam W

Well-known member
#9
I'm not uploading the files separately, I'm uploading the zip via scp (it took me 5 times to type that - damn Apple autocorrect) and unzipping directly on the server.

When running unzip -Z, I do see permissions:

Screen Shot 2017-09-04 at 20.05.47.png

I only very recently reinstalled Sierra, so I highly doubt it's something I've changed, as it was doing it on the High Sierra beta I had installed before as well.

Liam
 

Liam W

Well-known member
#10
I just downloaded 2 random add-ons from the resource area, Redis View Counters by @Xon and Preview Last Post by @DragonByte Tech. They both had world writable permissions in the zip unzip -Z.

(EDIT: Whoops, they both have world writable. Rushing a bit there.)

Just for the sake of completeness, I downloaded the XF2 DP10 ZIP and when using unzip -Z, the permissions look standard.

Liam
 
Last edited:

Snog

Well-known member
#11
When I first checked, I checked with 7-zip. I checked this time with the straight unzip -Z and you are correct. The zip file does contain different permissions that what are on the server itself...

Server permissions:
serverperms.png

Zip permissions:
zipperms.png

At least now there's another confirmation that it is happening. ;)
 

DragonByte Tech

Well-known member
#12
For the record, here's the code used by our eCommerce software to generate the zip:

PHP:
        // Begin the zip
        $zip = new ZipArchive();
        if (($result = $zip->open($filepath, ZIPARCHIVE::CREATE | ZIPARCHIVE::OVERWRITE)) !== true)
        {
            // Couldn't open the zip
            throw new Exception($vbphrase['dbtech_vbecommerce_invalid_temp_dir']);
        }

        foreach (VBECOMMERCE_FILE::$map as $filename => $shortfile)
        {
            // Grab the extension
            $ext = strtolower(VBECOMMERCE_FILE::fetch_extension($filename));
            
            switch ($ext)
            {
                case 'png':
                case 'gif':
                case 'jpeg':
                case 'jpg':
                case 'psd':
                case 'ttf':
                case 'zip':
                case 'ogg':
                    $zip->addFile($filename, $addOnDir);
                    break;
                
                default:
                    // Various replacements on the file contents go here
                    
                    $zip->addFromString($addOnDir, $file);
                    break;
        }

        // Finally close the zip
        $zip->close();
I had this problem with unzip and macOS' default zip extractor too, so I switched to The Unarchiver which does not suffer from this problem.


Fillip
 

Chris D

XenForo developer
Staff member
#13
We have tracked this down to a change within ZipArchive in PHP 5.6 which changed the previous default behaviour (not certain but it literally may have just been world writeable by default, though I'm not able to account for some difference in behaviour when using different code to create the Zip).

Long story short, PHP 5.6 introduced a setExternalAttributesName method and this can be used to give us the desired effect, see http://php.net/manual/en/ziparchive.setexternalattributesname.php.

Our desired effect in this case is just making sure the releases are built with consistent permissions inside which we've gone for 0755 for directories and 0644 for files. Behaviour is unchanged in PHP 5.4 and 5.5.