Access denied for anonymous users with "view private files" and "Document: download any file" permissions

File entity will also deny access to the direct file url (system/files/path/to/file) for anonymous users who have "view private files" permission.

file_entity_file_download() checks access by passing the "view" op to file_entity_access() - even though it is possible to grant the appropriate view permission to anonymous users, this will be ignored:

    if (!empty($wrapper['private'])) {
      // For private files, users can view private files if the
      // user is not anonymous, and has the 'view private files' permission.
      if (!empty($account->uid) && user_access('view private files', $account)) {
        return $rights[$account->uid][$cache_id][$op] = TRUE;
      }

View access at file/fid is denied because in that case file_entity_file_entity_access() returns FILE_ENTITY_ACCESS_IGNORE, but that then falls back to the default "view" behavior $account->uid check as above. No anonymous view.

Download access at file/fid/download is denied for reasons I have not yet figured out.

This is a major WTF for site builders. If somebody wants to grant those permissions to anonymous users and is able to do so, the expectation is that they will be honored.

It's certainly easy enough to patch. In my case I implemented hook_file_entity_access() to allow direct access to the file uri.

But I am wondering if this restriction is "by design" for some good reason. If so, the permissions are contradictory and altering the permissions form to disable the anonymous checkboxes could perhaps be considered.

Just to clarify: Not all anonymous users. We are using private files because we want to decide whether an anonymous user can download them based on whether the user has previously supplied a name and email address (we check a cookie). If they have, we give them the file. If not, we need to present a form to collect that data.

Yes, but it struck me as a major WTF the way that file entity blindly overrides the anonymous permission. Anonymous users have no direct access to file/fid paths, all interaction with downloadable documents uses the system file path, yet file entity blocks access to that unless something explicitly allows it by implementing the file entity hook - not really a logical extension of core's allow-by-default handling for private files, in my view.

Thanks for the fix and commit, appreciated.