The module generates temporary files in the site specified private temp directory. The code responsible for this appears in the file

$dir = file_directory_temp() . '/views_plugin_display';

The views_plugin_display directory is properly created and the permissions on the directory are set as 776 with the user apache and the group apache. However, the files created in that directory are created with 600 permission, read/write for the owner only. This occurs on line 605 of the aforementioned file.

   * Write to the output file.
  protected function outputfile_write($string) {
    $output_file = $this->outputfile_path();
    $handle = fopen($output_file, 'a');
    if (fwrite($handle, $string) === FALSE) {
      $this->abort_export(t('Could not write to temporary output file for result export (@file). Check permissions.', array ('@file' => $output_file)));

This causes issues when trying to sync to/from remote head using Aegir as Aegir cannot use the group write permission to sync the file.

Steps to reproduce from a fresh install of the module.

  1. Create a view that exports some data. (We have only tested with .xls)
  2. Use the view to export some data. The following should appear on the result screen.
    • The directory sites/ has been created.
  3. The file will download successfully. However, if you look at the file on the server in your /temp directory, you will see the file does not have 660 permissions, rather only 600.

Proposed resolution

I am curious as to why the fopen() is using the 'a' mode. Perhaps changing that to 'wb' would resolve this issue. I haven't been able to find much information about how permissions are generated when php writes the file. This issue is appearing on Red Hat Enterprise Linux 6.


Steven Jones’s picture

Version: 6.x-3.0-beta5 » 7.x-3.x-dev

Let's get this fixed in 7.x-3.x first, then backport.

Steven Jones’s picture

Version: 7.x-3.x-dev » 6.x-2.x-dev
Status: Active » Patch (to be ported)

Pushed a fix for 7.x-3.x.

Steven Jones’s picture

Status: Patch (to be ported) » Fixed

And pushed a fix into 6.x-2.x.

theMusician’s picture

I tested both patches and they appear to work perfectly.

Thank you.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

mauritsl’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
Status: Closed (fixed) » Active

These patches only work when all sites are running under the same user (i.e. "www-data"). The problem persists for webservers with different users per website (via suexec or fastcgi). The permission should be 1777 in that case.

Steven Jones’s picture

Status: Active » Closed (fixed)

The permissions allow users in the same group as the webserver to read and write to the file. I'd suggest that you need to add some users to the web server group rather than changing the permissions the file.