1

Disclaimer: I have found a way to fix this problem short-term, but I'm curious if anyone can explain to me why it's happening, or if someone has found a better fix than what I'm doing. If it exists already, Google has not revealed it to me.

Problem: (on a LAMP Server) When I use 'drush up' to update a module, or even core, the selinux context on the files is changed. This is new behavior as far as I can tell. I have used 'drush up' to update core and modules in the past with no problems. The changed selinux context results in a WSOD. To fix this, I run restorecon -R on the drupal root, which results in a series of

unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0

and then things work again, until the next 'drush up'. If I have multiple modules to update I either update and restorecon repetitively, or take my chances and drush up -y, restorecon, and then hope for the best (not ideal obviously).

Drush 7 and Drush 8 both behave this way. Oddly enough, when I 'drush dl' a module, it's brought in to the modules folder with the appropriate selinux context. Based on an ll -Z of files in the temp folder, I'm guessing (emphasis on guessing) that the files are getting moved from there rather than copied during an update, but I do not know enough about the inner workings of drush to be able to trouble shoot. Any insight would be welcome. Thank you.

3
  • 1
    Adding the --debug option to the command will give you a verbose output of what it's doing which should help in finding what might be causing it.
    – Shawn Conn
    Oct 22, 2016 at 6:39
  • 1
    This isn't really a Drupal or Drush question as it is about PHP and SELinux. A normal copy (using cp on the command line) would change the selinux context to the context of the parent directory. Either the context of the parent directory (sites/all/modules or similar) is wrong or copying using PHP bypasses the normal SELinux mechanisms. The normal problem with PHP and SELinux is connected to move_file_upload, but I don't think that is the case here as Drush is a command line tool. Using --debug as suggested is probably needed to see what is going on.
    – hansfn
    Oct 22, 2016 at 18:34
  • Thank you both for pointing to --debug. While I don't have it all figured out yet, I think I've nailed down the basic problem. Drush uses php's rename() function, which is a move and not a copy. If rename isn't available for some reason, drush performs a copy followed by a delete. By commenting out the portion that uses rename() and allowing the fallback copy/delete to happen, I get the functionality that I want/expect. Thanks again.
    – J.P.
    Oct 24, 2016 at 15:50

1 Answer 1

1

Drush downloads the new files into /tmp, which creates them with the wrong SELinux context. Drush then renames (moves) the new files rather than copying them, which maintains the wrong context.

There's more info at https://github.com/drush-ops/drush/issues/2412

diff --git a/includes/filesystem.inc b/includes/filesystem.inc
index 0d0f499..878b7d8 100644
--- a/includes/filesystem.inc
+++ b/includes/filesystem.inc
@@ -323,7 +323,7 @@ function drush_move_dir($src, $dest, $overwrite = FALSE) {
     return drush_set_error('DRUSH_DESTINATION_NOT_WRITABLE', dt('Destination directory !dest is not writable.', array('!dest' => dirname($dest))));
   }
   // Try rename. It will fail if $src and $dest are not in the same partition.
-  if (@drush_op('rename', $src, $dest)) {
+  if (FALSE && @drush_op('rename', $src, $dest)) {
     return TRUE;
   }
   // Eventually it will create an empty file in $dest. See

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.