Active
Project:
Drupal core
Version:
main
Component:
configuration system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
15 Feb 2013 at 00:48 UTC
Updated:
18 Mar 2025 at 16:00 UTC
Jump to comment: Most recent
Goal
- Decrease security checks and validations to a single point of failure.
Proposed solution
- Change the installer to expose a required setting for the private filesystem path.
- Store the private filesystem path in settings.php.
- Create config directories in the private filesystem path.
Comments
Comment #1
hass commentedMaybe it's a good idea to have a third setting named "Configuration directory". This way we are able to make sure this never clash with file management tools like IMCE.
Comment #2
berdirWhile we could initialize it based on a private:// sub-directory, I really think we should do this: #1887750: Use path relative to DRUPAL_ROOT in configuration directories.
Comment #3
sun#1887750: Use path relative to DRUPAL_ROOT in configuration directories does not seem to change or improve the situation with regard to this issue in any way — the directories are still in the publicly accessible space and thus require manual futzing with security and verification that files are not world-readable.
But that's the whole point here:
Comment #4
hass commentedFully agree with sun. What do you think about config:// or configuration:// as an extra configuration option?
Comment #4.0
hass commentedA
Comment #5
sunconfig:// would not be a tangible improvement compared to now, as it would still be a one-off filesystem location. The point of private:// is that it is a single location and bucket for many (different) files that share the need of a non-world-readable storage.
I can see your point with private:// though. When configured accordingly, all user-uploaded files are stored in there, and a potential file browser UI would have to cater for not exposing certain subdirectories in it.
We could investigate a system://
At minimum, we'd want to use that for the config active and staging directories, as well as the PHP storage.
Comment #6
hass commentedsystem://sounds good, too. However it's named it must be located in a non-world-readable storage. I just thought it is a clean abstraction fromprivate://folder where the content could also get listed by file management tools like IMCE.Comment #7
berdirEnforcing a path below private:// would make that required, do we really want that?
What #1887750: Use path relative to DRUPAL_ROOT in configuration directories does is making the configuration work the same way as the public/private/temporary path. If it's relative, then it starts from DRUPAL_ROOT and if not, then it's absolute. No need to have a separate flag for that anymore. Right now, the configuration path *looks* as if it would be below public:// but that's a lie, it just has the same default value. So if you e.g. move the public files directory, you must not move the config directory or change that as well and make it "absolute".
If we expose the private path setting in the UI then we could default the configuration directory to be below private, but those two settings should IMHO not overlap.
Weither we use or introduce config:// or something else like that doesn't matter, that's just a fancier way to access it than a helper function, both need configuration behind it.
Comment #8
sunI just followed up on #1856766: Convert file_public_path to the new settings system (make it not configurable via UI or YAML), which is also closely related.
Yes, I understand that #1887750: Use path relative to DRUPAL_ROOT in configuration directories changes the config directory path names to be no longer "related" to the public files directory. What it does not change or improve in any way is:
With system://, we imply a completely new, required filesystem location. It would be a hard-coded stream wrapper, which would target to
settings('file_system_path'). That's where config directories live, and PHP code is dumped into. The filesystem path must exist and be writable for Drupal to operate. Drupal will only verify that this single filesystem path is secured.Comment #8.0
sunA
Comment #9
sunComment #10
mtiftCan we close this one now that #2161591: Change default active config from file storage to DB storage went in?
Comment #11
hass commentedMaybe less priority, but the issue still exists if you import/export your configuration.
Comment #25
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.