K here it goes.

So we run RHEL 6 with selinux.

Drush omega-wizard does not respect acl or selinux context.

For instance here is the default omega context when using drush dl omega: unconfined_u:object_r:httpd_sys_content_t:s0
however when i run drush omega-wizard in sites/all/themes my new subtheme recieves this context: unconfined_u:object_r:user_tmp_t:s0

this makes it so the theme can't be found by httpd and drupal. it also spits out some nice errors:

Notice: Undefined index: d7_stuckeman in drupal_theme_initialize() (line 100 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _drupal_theme_initialize() (line 146 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _theme_load_registry() (line 335 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _theme_load_registry() (line 319 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _theme_build_registry() (line 713 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _theme_build_registry() (line 713 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _theme_build_registry() (line 713 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in _theme_save_registry() (line 343 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Undefined index: d7_stuckeman in theme_get_setting() (line 1431 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in theme_get_setting() (line 1468 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).
Notice: Trying to get property of non-object in theme_get_setting() (line 1478 of /var/www/html/stuckeman.psu.edu/includes/theme.inc).

but those are just because technically according to selinux this set of files doesn't exist.

the fix is to run the chcon command or the restorecon command... but this is probably not what you had in mind, right?

Do you have any desire to try to make drush omega-wizard respect SElinux and ACL contexts/permissions? or do I just need to restore the contexts each time i install a new subtheme?

If you need more info i will be happy to provide it and test possible solutions. I think this is a "bug" however, i know this doesn't affect people who aren't using enterprise systems with hardened Linux environments.

Comments

bradallenfisher’s picture

here is the command to get your theme directory back to default context if you don't have special perms set up.
chcon -R -t httpd_sys_content_t your_themname

fubhy’s picture

Hi. Interesting problem. All file system interactions happening during the sub-theme generating process run through Drush's API / Helper functions (e.g. drush_mkdir(), drush_move_dir(), etc.).

I just double-checked and can confirm that there is really no custom logic in Omega for writing or even touching files other than line 763 in omega.drush.inc which only touches files that already exist and were written by one of the Drush helper functions beforehand. So there is really nothing in there that creates files directly and would thereby potentially cause problems with file/directory properties.

As I do not currently have a SELinux stack running anywhere can you maybe try to dig a little deeper and find out what exactly is writing incorrectly attributed files? At this point my guess would be that it's Drush's fault, not Omega (because of the aforementioned reasons).

That's all the help I can give you atm. I am afraid :/

fubhy’s picture

Oh! I know why it receives the tmp context... When generating a new subtheme we first put it in /tmp (or whatever you set as your tmp directory). Once finished with the generating process, we move the files into the destination provided during the wizard steps. Apparently, drush_move_dir() does not reapply the (new) context... @see line 214 in omega.drush.inc... Would you mind playing around with that a bit and directly placing the files in the final destination instead of the temp dir? Instead of creating the subtheme in the tmp dir we could also just clean up all files in case of a failure... Will get a bit more messy (code-wise) though.

bradallenfisher’s picture

Yes Sir... I saw that as well, if the problem is simply that it goes to /tmp first, then destination, I will try to work on a patch.