Contrib.social

File usage is not tracked by revision, leading to private files embedded in text fields in old revisions being accessible when they shouldn't be

Open on Drupal.org →
Created on 5 June 2019, about 6 years ago
Updated 16 June 2025, 7 days ago

Problem/Motivation

Forgive me if this issue has been covered by some of the other issues linked to from 🌱 Dealing with unexpected file deletion due to incorrect file usage Active but I couldn't find this specific case listed anywhere.

The issue stems from the fact that file usage is only tracked on an entity's id, not the specific revision that a file is being used in. This can lead to instances where a file uploaded to the private file system and linked to via a text/text_long/text_with_summary field is still accessible in an unpublished revision.

Steps to reproduce:
1) Upload a file to a field that stores files in the private file system
2) Reference that file in a text field (like the body field on a node) (we'll call this Node A)
3) Delete the file from the field you previously uploaded it to
4) Create a new revision of Node A, deleting the link to the file in the text field and unpublishing the old revision (WBM or CM may be required here)
5) Make sure the new revision of Node A is published
6) Attempt to access the file by path directly

Expected:
File is inaccessible as it isn't referenced by a published revision.

Actual:
File is accessible due to editor's implementation of hook_file_download. This gathers usage via \Drupal::service('file.usage')->listUsage($file); and checks whether the user is able to view the entity. Since the entity is published, and it only loads the current revision, the user is able to access the file.

The use case for needing to deny access to these files comes back to what the private file system is usually used for: limiting access to files. If a file has been removed and a new version has been uploaded, but the previous version was once linked to in a text field then it should not be accessible.

Proposed resolution

TBD

🐛 Bug report
Status

Active

Version

11.0 🔥

Component

file system

Created by

🇦🇺Australia acbramley

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 7 days ago →
    🇺🇸United States smustgrave

    @acbramley wonder if those other issues addressed this?

  • Comment 7 days ago →
    🇦🇺Australia acbramley

    Unfortunately not, I can still reproduce this on HEAD.

  • Comment 4 days ago →
    🇦🇺Australia seth h

    This issue has an inverse effect as well, namely that when a new file is uploaded to an unpublished revision on a previously published entity, that file is permanently access denied.

    Example: A draft update to some node has updated the file, and the reviewing user wants to check the file contents before marking the revision as published.

    This is caused by the fact that the published revision is loaded when loading file references in `file_get_file_references()`.

    There is even a comment documenting this.

    // Iterate over the field items to find the referenced file and field
// name. This will fail if the usage checked is in a non-current
// revision because field items are from the current
// revision.
// We also iterate over all translations because a file can be linked
// to a language other than the default.
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024