Posted by fjeder on Wed, Jul 03, 2024 - 4:26am

Hey Guys

I have a website where I have created a content type with a file field where I have set the Upload option to Private files. I have also set the private file path to files/private and set the default download method to "Private local files served by Backdrop".  If I create a new node and upload a File, the path to that file is domain.com/system/files/test.pdf However if I visit that URL in an incognito browser the file is still accessible. 

I have checked that the files/private folder has the .htaccess file neccessary generated by Backdrop, and I have also tried to set the private file path to a folder outside Backdrop root with the same result. 

I have checked that anonymous users doesn't have the "view private files" permission as well. 

I am on an apache server with PHP Version 8.2 and Backdrop version 1.28.1. I have tried this on two different backdrop sites with the same result.

Is this a bug in the CMS or am I missing something?

Thank you. 

Accepted answer

Hi fjeder.

I agree this is confusing and can be seen as a bug. This case highlights the complexity of permissions when they overlap. You are dealing with two entities: the file entity itself, and the content type that contains a file reference field.

  • If you try to access the file entity (with `file/[FID]') and that the file of that entity is stored as private, then the permission "View private files" applies.
  • On the other hand, if you allow Anonymous to view content, and that content has a file reference field to a private file, Anonymous WILL be able to open that file

Perhaps this approach should be revised. For the time being, if you wish to disallow Anonymous from accessing a file through a node's file reference field, you'll need to use the contrib Content Access (or something similar) to disallow Anonymous from seeing the node itself.

More to your point, and in addition, accessing a file through the direct download link (e.g system/files/FILE_NAME) bypasses the permission check. Using the file entity URI on the other hand file/[FID] will apply the permission.

This is confusing and has been controversial in the past. There are some issues in the issue queue about file Permissions, and Permissions in general, but these are tricky things to change and not be backward compatible breaking changes. So, for the time being, these are "the rules of the game".

Most helpful answers

Accessing a file through the

Accessing a file through the direct download link (e.g system/files/FILE_NAME) bypasses the permission check. Using the file entity URI on the other hand file/[FID] will apply the permission.

As I understand the private file system, the permission checks work generally fine, but it's hard to get the head around it. One could say, the private file system  is there to 'follow' your content permissions. So, it depends where you upload such a file: When you upload a file to a public content item, it remains accessible. When you upload it to a protected content item, you are not allowed to access the file at  a path like system/files/my-private-file.pdf.

Comments

Wed, Jul 03, 2024 - 7:01am by argiepiano

Hi fjeder.

I agree this is confusing and can be seen as a bug. This case highlights the complexity of permissions when they overlap. You are dealing with two entities: the file entity itself, and the content type that contains a file reference field.

  • If you try to access the file entity (with `file/[FID]') and that the file of that entity is stored as private, then the permission "View private files" applies.
  • On the other hand, if you allow Anonymous to view content, and that content has a file reference field to a private file, Anonymous WILL be able to open that file

Perhaps this approach should be revised. For the time being, if you wish to disallow Anonymous from accessing a file through a node's file reference field, you'll need to use the contrib Content Access (or something similar) to disallow Anonymous from seeing the node itself.

More to your point, and in addition, accessing a file through the direct download link (e.g system/files/FILE_NAME) bypasses the permission check. Using the file entity URI on the other hand file/[FID] will apply the permission.

This is confusing and has been controversial in the past. There are some issues in the issue queue about file Permissions, and Permissions in general, but these are tricky things to change and not be backward compatible breaking changes. So, for the time being, these are "the rules of the game".

Wed, Jul 03, 2024 - 7:08am by argiepiano

And two more things:

  • Drupal 7 behaves this way too
  • The help text in "Default download method" is misleading. It says "This setting is used as the preferred download method. The use of public files is more efficient, but does not provide any access control."  This makes it seem that the use of "Private local files served by Backdrop" will enforce access control, but it does only in some cases. 
Olafski's picture

Wed, Jul 03, 2024 - 7:30am by Olafski

Accessing a file through the direct download link (e.g system/files/FILE_NAME) bypasses the permission check. Using the file entity URI on the other hand file/[FID] will apply the permission.

As I understand the private file system, the permission checks work generally fine, but it's hard to get the head around it. One could say, the private file system  is there to 'follow' your content permissions. So, it depends where you upload such a file: When you upload a file to a public content item, it remains accessible. When you upload it to a protected content item, you are not allowed to access the file at  a path like system/files/my-private-file.pdf.

Thu, Jul 04, 2024 - 12:28am by fjeder

Hey guys 

Thank you for your help - as pointed out by argiepiano, removing the "View published content" permission did the trick, however I agree that this is not very transparent, but if these er the rules of the game, that is just the way it is.. :)