Repository navigation
[Bug]: The option forbidden_filenames is not considered in blacklist check blacklisted_files #49014
Copy link
Copy link
Closed
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap30-feedbackbugfeature: filesfeature: filesystemhotspot: filename handlingFilenames - invalid, portable, blacklisting, etc.Filenames - invalid, portable, blacklisting, etc.
Description
⚠️ This issue respects the following points: ⚠️
- This is a bug, not a question or a configuration/webserver/proxy issue.
- This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- I agree to follow Nextcloud's Code of Conduct.
Bug description
Emptying the forbidden_filenames option in config.php still blocks file uploads with the file name ".htaccess".
This might be due to the function isFileBlacklisted() in Filesystem.php, which considers the deprecated option blacklisted_files only. As soon as I empty this option, everything works as expected.
server/lib/private/Files/Filesystem.php
Lines 435 to 444 in 14ff0e4
| public static function isFileBlacklisted($filename) { | |
| $filename = self::normalizePath($filename); | |
| if (self::$blacklist === null) { | |
| self::$blacklist = \OC::$server->getConfig()->getSystemValue('blacklisted_files', ['.htaccess']); | |
| } | |
| $filename = strtolower(basename($filename)); | |
| return in_array($filename, self::$blacklist); | |
| } |
Steps to reproduce
- In config.php add
'forbidden_filenames' => array() - Create a file named .htaccess and try to sync it (not using an Apache web server, of course)
- The file will be blocked
Expected behavior
When allowing the upload of ".htaccess" files by emptying the forbidden_filenames option, the files should be synced.
Nextcloud Server version
30
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.3
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 28 to 29)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
Metadata
Metadata
Assignees
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap30-feedbackbugfeature: filesfeature: filesystemhotspot: filename handlingFilenames - invalid, portable, blacklisting, etc.Filenames - invalid, portable, blacklisting, etc.
Type
Projects
- StatusShow more project fieldsDone
Activity
[-][Bug]: The option forbidden_filenames is not considered in blacklist check[/-][+][Bug]: The option `forbidden_filenames` is not considered in blacklist check `blacklisted_files`[/+]Moritz-Wohlgenannt commentedon Jan 22, 2025
I was just about to repot this as well. Took me 5 hours yesterday to find the offending code in the codebase. I found that lib/private/Files/FilenameValidator.php looks for forbidden_filenames and defaults to .htaccess while lib/private/Files/Filesystem.php looks for blacklisted_files and defaults to .htaccess if its empty. My workaround was to set both in my config.php. This brings back the issue that my log is flooded with the blacklisted_files is deprecated warning but at least our users can continue syncing .htaccess files as they ave before.
Really I think both functions should evaluate forbidden_filenames and blacklisted_files or forbidden_filenames in the config should populate the blacklisted_files array as well for legacy code to not trip up...
susnux commentedon Jan 22, 2025
forbidden_filenamescannot be used here, this function is used in system internal methods that need to allow to write files with e.g. non windows compatible filenames.Meaning this method is also used for non-user files (system only) and is intended for filenames that might have a bad impact on the server not on the user.
So the difference is that one is to enforce sync compatibility (e.g. windows forbidden filenames) the other is to protect the server (forbid
.htaccesswhich could make the data directory readable if badly configured by the admin).Moritz-Wohlgenannt commentedon Jan 22, 2025
Hi susnux,
well this is problematic, since Nextcloud prints this to the logs: System config option “blacklisted_files” is deprecated and will be removed in Nextcloud 34, use “forbidden_filenames” instead.
This prompted me to change my config from blacklisted_files to forbidden_filenames. If both are required and doing different things, then the message in the logs is highly misleading.
I understand why .htaccess is a default for a blacklisted file, but if there is a configuration option to allow it (and there are good reasons to allow it, when using nginx for example) it is problematic if that configuration option does indeed not allow it and nextcloud keeps hindering users who try to upload upload .htaccess files.
Best regards,
Moritz