Private stored default images give access denied

I think the problem is in the file.module function: file_file_download().
The result of file_get_file_references($file, NULL, FIELD_LOAD_CURRENT, $field_type) is always empty because there are no fields connected, since it is a default image.

I created an image field in a taxonomy. The default image is private, but it even isn't shown in the taxonomy page of this term: ..../taxonomy/term/999. There no mention of an image at all in the html, except for the feed icon. (I applied the patch from http://drupal.org/node/1327224 #7 to have my images, created in a term, to be shown.)
After deleting the default image, setting the upload to public file system in the image_field, saving and uploading the default image again, the default image is shown in the taxonomy/term page.
But after resetting the file system to private the image is disappeared again. Setting it to public does reappear the default image.

I am having a similar problem after inserting images using the media_gallery module.
The images are references in file_managed as:

+-----+-----+--------------+------------------------+------------+----------+--------+------------+-------+
| fid | uid | filename     | uri                    | filemime   | filesize | status | timestamp  | type  |
+-----+-----+--------------+------------------------+------------+----------+--------+------------+-------+
|  71 |   1 | example.jpg | private://example.jpg | image/jpeg |   177049 |      1 | 1334603309 | image |
+-----+-----+--------------+------------------------+------------+----------+--------+------------+-------+

I found that the functionality works by changing the following to the image.module file:

  diff --git a/modules/image/image.module b/modules/image/image.module
index 933dbc5..1915a5a 100644
--- a/modules/image/image.module
+++ b/modules/image/image.module
@@ -316,7 +316,17 @@ function image_file_download($uri) {
   if (count($files)) {
     $file = reset($files);
     if ($file->status) {
-      return file_file_download($uri, 'image');
+      return array(
+       // Send headers describing the image's size, and MIME-type...
+       'Content-Type' => $file->status,
+       'Content-Length' => $file->file_size,
+       // ...and allow the file to be cached for two weeks (matching the
+       // value we/ use for the mod_expires settings in .htaccess) and
+       // ensure that caching proxies do not share the image with other
+       // users.
+       'Expires' => gmdate(DATE_RFC1123, REQUEST_TIME + 1209600),
+       'Cache-Control' => 'max-age=1209600, private, must-revalidate',
+      );
     }
   }
 }

My rational for this change is, that once the thumbnail/etc. is created in the styles directory, access is fine. When the styles entry is not yet created, I was getting and "access denied" error.

This workaround breaks the privacy requirement, and the image can now be viewed even when the user is not logged on. It works for me, because I am only concerned with the privacy of the content and other filetypes.

I also posted a brief summary in the media_gallery issue queue (http://drupal.org/node/1274464).

Either this is relevant also for the latest Drupal release, or this issue should be closed.
Guessing the former and updating the version tag accordingly.

Isn't this basically the same issue as reported here? #1414990: Orphaned private files can not be accessed

Hello for me the same issue.. :-(

Since in my case I don't care if the default image is public I've gone into the database and manually changed the file to public, which makes it display.

Can anyone explain how and where I can do that?

Best regards
Frank

Same issue,

I created a new image default on the user account and it is not displayed, but if the user insert the image will be display the new image

Here is a quick fix I used on my site
I used the hook_file_download to return a http header for default images

function private_default_image_fix_file_download($uri) {
    if (strpos($uri,"default_images") > 0) {
        return array("Accept" => "Accept");
    }
}

Working module attached

Hello Optalgin ,

thanks so much for your work. I will test your patch the next days and give feadback.

Best regards
Frank

Hi @fraweg
Please note this is not a patch, it is an independent module used to bypass this issue
at least until this known issue is fixed: #1414990: Orphaned private files can not be accessed

To use:

• Just put it in your www.yoursite.com/sites/all/modules directory
• Enable it under www.yoursite.com/admin/modules

It works on my own site, it should work on any :)

I've just run into this issue, I changed the patch slightly as I noticed it wasn't sending the correct content type (basically just copied from image_file_download()).

function private_default_image_fix_file_download($uri) {
  if (strpos($uri, "default_images") > 0) {
    // Check that the file exists and is an image.
    if ($info = image_get_info($uri)) {
      return array(
        // Send headers describing the image's size, and MIME-type...
        'Content-Type' => $info['mime_type'],
        'Content-Length' => $info['file_size'],
        // By not explicitly setting them here, this uses normal Drupal
        // Expires, Cache-Control and ETag headers to prevent proxy or
        // browser caching of private images.
      );
    }
    else {
      return -1;
    }
  }
}

Thank you for your "module".

I just uninstalled IMCE module from my drupal7 site and I wasn't aware of that there where an option in it that done the same thing by default and that I can't live with it:
"IMCE serves all files under private files directory without applying any access restrictions. This allows anonymous access to any file(/system/files/filename) unless there is a module restricting access to the files. Here you can disable this feature."

I installed yours and it addresses that need well although it is still not the good way.

One note on the quick fix presented in #7 and #10:
this will allow access to private files under the default_images folder. For default images this shouldn't be a big deal, but you can always extend the hook implementation with some permission checks like user_is_logged_in() etc.

thanks for the tip @nibo and @Optalgin. Final .module file should read something like this:

<?php
if(user_is_logged_in()){ 
	function private_default_image_fix_file_download($uri) {
		if (strpos($uri,"default_images") > 0) {
			return array("Accept" => "Accept");
		}
	}
}

I hope this bug is resolved in core soon!

present in drupal 7.34 , shouldn't it fixed in core?

to reproduce
1 setup private filesystem
2 add image field to custom content type with private file system
3 upload no-avatar.jpg as default image for above image field.
4 create a node of custom content type without uploading to image field
5 visit the newly created node with broken image link, even for user 1
6 in log you will see access denied

In directory image permission is set to 664 with www-data:www-data.

when image is set in step 4 then newly uploaded files is accessible which has the same 664 permission

changing priority to major not because I am still having problem and looking for solution(which is already posted in this issue) , its because no core maintainers had paid their attention to this issue. Use case might looks like minor but causing unwanted logs in watchdog and still bug is a bug :).

Yes, this is the real bug of the core.

changing version to dev.

An entire version of Drupal has come and gone with a bug like this still in it?

This appears to still be in the latest Drupal 8 release, so should be fixed there first.

I am experiencing the same thing as #14 in 7.50.

to reproduce
1 setup private filesystem
2 add image field to custom content type with private file system
3 upload no-avatar.jpg as default image for above image field.
4 create a node of custom content type without uploading to image field
5 visit the newly created node with broken image link, even for user 1
6 in log you will see access denied

Moving back to Drupal 7.x since that's what I'm working on at the moment. Hopefully this is still helpful.

This patch takes inspiration from comment #10, and based on the feedback of #12 adds a new permission "view private default images" to avoid making assumptions about which Roles should be able to view private default images.

Finally, with the correct root directory.

The steps indicated in #21 sound like a good case to add a regression test.

Tests are the hard part!

There was an existing test for viewing default private images, but it checked only the HTML of the image field, which is rendered fine, without checking access to the file itself. Attached is a "some-tests" patch which will intentionally fail, and then there's a patch with additional tests that make use of the new permission to view private default images combined with the solution.

Awesome, thanks @ShaunDychko, sounds like the new tests provide a bit better test coverage in general.

The D8 version of this should be created as a follow-up task. (I could be miss-understanding the new policy) https://www.drupal.org/core/backport-policy#d7

Turns out the D8 issue already exists. Set as the "parent" issue for this one.

This will need to be committed to 8.x first :)

Patch in #31 by ShaunDychko worked for me, thanks.

Subscribe.

Here is the 8.x issue, that is still under review.

If you want this fixed in 7.x, go test the 8.x patch and mark the 8.x issue as RTBC
#2107455: Image field default value not shown when upload destination set to private file storage

#31 Patch did not work for me (Drupal 7.61). Only users having "admin role" are able to see any generated styles.
Actually problem (in my case) was invalid overrides done with https://www.drupal.org/project/private_files_download_permission .

Did this ever get committed into core? It appears like it didn't. I think I may have found a way around patching core using hook_file_download() if someone else needs this. Might keep you from patching every update, if it wasn't committed:

/**
 * Implements hook_file_download().
 */
function MYMODULE_file_download ($uri){
  if (substr ($uri, 0, 25) == 'private://default_images/') {
    $info = image_get_info($uri);
    return [
       'Content-Type' => $info['mime_type'],
    ];
  }
}

This would also allow you to customize it even more for specific files. You could do a custom permission check as well using hook_permission() and then checking user access.

#42 works fine