Fixed Exported add-on files have world-writable permissions

[Liam W]

Affected version

XF2 DP 10

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]

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

 

[Liam W]

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

No, and other outputted files have the correct permissions...

Liam

 

[Mike]

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]

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]

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, 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]

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...



Checked a second file to be sure:


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


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

 

[Liam W]

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:



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]

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

 

[Snog]

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:


Zip permissions:


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

 

[DragonByte Tech]

For the record, here's the code used by our eCommerce software to generate the zip:

        // 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]

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.