search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 39 forks source link

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

Open novid opened 5 years ago

novid commented 5 years ago

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 ... Screenshot from 2019-06-06 17-39-10

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

olafgrabienski commented 5 years ago

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: https://github.com/backdrop/backdrop-issues/issues/2371

indigoxela commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

novid commented 5 years ago

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 commented 5 years ago

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 https://github.com/backdrop/backdrop-issues/issues/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 commented 2 years ago

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.