File System permission problems with v1.13.2 on Unix/Linux shared hosting

[novid]

Description of the bug
Due to permissions on this release (1.13.2) installation on shared hosting environments doesn't start properly.

Steps To Reproduce
To reproduce the behavior:

1. Download backdrop v 1.13.2
2. Extract on your shared hosting environment
3. Start the installation process

Actual behavior
Server responds with 5xx error ...

Expected behavior
Normal installation procedure would be started if following commands are run right after extraction step:
find <backdrop> -type d -exec chmod 755 '{}' \;
find <backdrop> -type f -exec chmod 644 '{}' \;

Additional information

• Backdrop CMS version: 1.13.2
• Web server and its version: Apache 2.4
• Operating System and its version: Unix/Linux Shared Hosting
• Browser(s) and their versions: Not Applicable

[olafgrabienski]

Hey @novid, thanks for reporting the issue! Do you think, Backdrop had a different behaviour with versions prior to 1.13.2?

Unfortunately I don't have time to reproduce the issue at the moment, but I however want to share the link to an issue thread where you find a lot of information about the history of file permission questions in Backdrop which may explain why the permissions are not set correctly for the mentioned use case: #2371

[indigoxela]

@olafgrabienski I can confirm the change in file permissions in 1.13.2.

Directory perms seem ok (755), but files really changed from 644 (prior to 1.13.2) to 666 (which is a potential security risk).

[novid]

@olafgrabienski I read all the comments #2371 and found that there is a drush command (fix-permissions) for resolving this problem on systems that provide SSH access. But not all of Unix/Linux shared hosting providers allow SSH access to hundreds or thousands of their customers, at least this a procedure on Middle East and North Africa and i don't know about other regions and their protocols.

So, this is a good and old idea of giving directories 755 and files 644 on LAMP applications. Major CMSs like Drupal, Joomla and WordPress took this approach for years and their core packages respect this scenario.

[novid]

@indigoxela There are little differences In Unix/Linux shared hosting environments based on RedHat (CentOS) and Debian (Ubuntu):

• user of system which belongs to web server group
• group of web server (www in RedHat and www-data in Debian)
• umask of system (which is different in major versions)

Granting write permission to directories is normal due to giving access inside the directory for required files but this same task on files in only necessary for shell scripts like bash and similar tools not regular php files like install.php or update.php because these files are not like shell scripts and they execute inside web server modules whether MPM, FastCGI or FPM.

[indigoxela]

@novid I'm pretty sure, the permission change was not by intention and should get reverted to 755/644 (the previous default) with the next Backdrop release.

I do know, some hosting providers force directory and file perms on ftp upload, but we should not rely on that.

[olafgrabienski]

@novid From reading #2371 I understood that the issue was fixed (755 for directories, 644 for files) but that the fix isn't reflected in a .zip archive (which is in the download link on backdropcms.org). On https://github.com/backdrop/backdrop/releases, you can get a tar.gz as an alternative.

That said, I'd also prefer 755/644 for all archives / formats, but I don't know if it's possible.

[indigoxela]

@olafgrabienski the file permissions in zip releases were OK previously to 1.13.2, the change was introduced with 1.13.2.

[novid]

With that said, it's not a major problem and we can close the issue. If anything happens in the future we can re-open this issue and link it back to #2371.

[indigoxela]

We should have one open issue to reference in a new pull request.

That could be this one (I'd recommend) or the old one #2371

Doing a fresh "git clone" shows that some php files have wrong permissions.

./index.php
./core/cron.php
./core/update.php
./core/install.php
./core/authorize.php
./core/modules/update/update.theme.inc

These files have 755. In the release zip all files including those listed above turned to 666.

[quicksketch]

In the release zip all files including those listed above turned to 666.

I think our Zip files don't maintain any permissions (I could be wrong). The permissions you get upon expanding are the default set by umask: https://docs.oracle.com/cd/E19683-01/817-3814/userconcept-95347/index.html

Shared hosts tend to try and reduce permissions issues by setting a umask and owner that matches that of the web server (so the web server and user account for FTP are generally the same). Some shared hosts require PHP files be executable, some do not. But in most cases they set the umask to match.

Apparently it's now possible to preserve permissions in Zip files, at the time we wrote the packager I don't think that was the case.

In any case, setting permissions consistently within Git is still a good idea.