Task #9787
Update Nginx configuration with downloads location
Status: | Won't fix | Start date: | 05/03/2016 | |
---|---|---|---|---|
Priority: | Medium | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Documentation / help | |||
Target version: | Release 2.4.0 | |||
Google Code Legacy ID: | Tested version: | |||
Sponsored: | No | Requires documentation: |
Description
After the finding aid upload changes AtoM allows to upload/download files to/from the downloads directory..
Related issues
History
#1 Updated by José Raddaoui Marín about 6 years ago
- Related to Feature #9627: Allow users to upload a PDF finding aid instead of generating one from AtoM's descriptions added
#2 Updated by Jesús García Crespo almost 6 years ago
- Assignee deleted (
Jesús García Crespo)
#3 Updated by Dan Gillean about 5 years ago
- Assignee set to José Raddaoui Marín
Radda do we need to do something on this in advance of the 2.4 release?
#4 Updated by José Raddaoui Marín about 5 years ago
- Assignee changed from José Raddaoui Marín to Jesús García Crespo
Hi Sevein, quick check ...
Would it be enough to include the downloads directory in the following rule? Like:
location ~* /(?:uploads|files|downloads)/.*\.php$ { deny all; return 404; }
Please, let me know what do you think.
#5 Updated by Jesús García Crespo about 5 years ago
What are you trying to achieve? I read the description of the ticket but I couldn't figure out what's the problem, sorry!
#6 Updated by José Raddaoui Marín about 5 years ago
I was thinking on avoiding malicious uploads for code execution to the downloads folder, but we're only allowing .pdf and .rtf uploads to that folder at the moment, so it may not be necessary ...
#7 Updated by Jesús García Crespo about 5 years ago
We only allow PHP execution when the request points to /index.php or /qubit_dev.php so I don't think we need to worry about that. These are the two relevant blocks in Nginx:
location ~ ^/(index|qubit_dev)\.php(/|$) { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_split_path_info ^(.+\.php)(/.*)$; fastcgi_pass atom; } location ~* \.php$ { deny all; return 404; }
Your change:
location ~* /(?:uploads|files|downloads)/.*\.php$ { deny all; return 404; }
.. could be combined with the extra block below if we wanted AtoM to run extra checks before the files are served to the user, like we do with uploads/.
location ~* ^/downloads/(.*)$ { include /etc/nginx/fastcgi_params; set $index /index.php; fastcgi_param SCRIPT_FILENAME $document_root$index; fastcgi_param SCRIPT_NAME $index; fastcgi_pass atom; }
But I think downloads/ is currently a store where we locate files with unrestricted access. My suspect is that changes are not required at the moment unless you guys want to revisit the different uses of downloads/ and double check that they're not making possible to disclose non-published materials.
#8 Updated by Dan Gillean about 5 years ago
One consideration: as of issue #10797, there's an option to generate all XML asynchronously as descriptions are added or edited - 2 subdirectories are created in the Downloads directory; one for EAD and one for DC. If the descriptions are not published, then public users shouldn't be able to access these downloads.
#9 Updated by José Raddaoui Marín about 5 years ago
- Status changed from New to Won't fix
- Assignee deleted (
Jesús García Crespo)
Great! Thank you both!
#10 Updated by Jesús García Crespo about 5 years ago
One consideration: as of issue #10797, there's an option to generate all XML asynchronously as descriptions are added or edited - 2 subdirectories are created in the Downloads directory; one for EAD and one for DC. If the descriptions are not published, then public users shouldn't be able to access these downloads.
Dan: and was that requirement captured and addressed already as part of #10797 in some other way?
#11 Updated by Dan Gillean about 5 years ago
Dan: and was that requirement captured and addressed already as part of #10797 in some other way?
I'm not sure, you would have to ask the developer, Mike Cantelon. Just wanted to make sure we were considering it.
#12 Updated by Mike Cantelon about 5 years ago
If a description isn't published it won't be exported and if it's published and gets changed to unpublished exports should get deleted.