Permissions for Composer installs

Support
1

I added composer to the right-click SSH via:

apt-get update && apt-get install -y wget
wget -qO- https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

All good.

I could navigate to a theme, and run composer install. Composer warns “Do not run Composer as root/super user! See How do I install untrusted packages safely? Is it safe to run Composer as superuser or root? - Composer for details”. The “Open as SSH” option seemingly has no choice apart from being root.

The real problem seems to start for the themes post-install script:

"scripts": {
    "build-theme": [
      "gulp build"
    ],
    "install-and-build-theme": [
      "npm install",
      "@build-theme"
    ],
    "install-standards": [
      "\"vendor/bin/phpcs\" --config-set installed_paths ../../wp-coding-standards/wpcs",
      "rm -rf vendor/squizlabs/php_codesniffer/CodeSniffer/Standards/PHPCompatibility",
      "cp -r vendor/wimg/php-compatibility vendor/squizlabs/php_codesniffer/CodeSniffer/Standards/PHPCompatibility"
    ],
    "post-install-cmd": [
      "@install-standards",
      "@install-and-build-theme"
    ],
    "post-update-cmd": [
      "@install-standards",
      "@build-theme"
    ]
  }

In particular, the --config-set line fails:

Screenshot 2017-07-17 10.54.41.png1355×183 30.5 KB

All of the files and directories seemed to be owned by 501 in the dialout group. The CodeSniffer.conf file is -rw-r--r-, but I’m not sure under which user Composer is running the script (despite being SSH apparently as root).

cd /app/public/wp-content/themes/utility-pro/vendor/squizlabs/php_codensniffer
chmod 666 CodeSniffer.conf

works (664 doesn’t), but requiring that seems like a symptom of something else.

2

Hi Gary,

You can ignore the root warning. That’s the only user that exists inside the Docker container.

As far as the permissions issue goes, I’d try going to Preferences » Advanced and disabling “Faster Docker Volumes”. Then, restart the site and see if the issue persists.

3

Hi Clay,

With the CodeSniffer.conf file back at 644, and the Faster Docker Volumes disabled and the site restarted, the permissions error persists.

The whoami is still root (obviously), but the files are now owned by www-data:staff.

4

Interesting!

What happens if you try editing CodeSnipper.conf with a simple nano command in the container?

5

The file successfully opens for editing.

6

If you try to make some changes and then press Ctrl + X then Y do you get a “permissions denied” error?

7

No - it saves fine (and the changes are persisted when the file is re-opened).