Task #9787

Update Nginx configuration with downloads location

Added by José Raddaoui Marín about 4 years ago. Updated about 3 years ago.

Status:Won't fixStart date:05/03/2016
Priority:MediumDue 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

Related to Access to Memory (AtoM) - Feature #9627: Allow users to upload a PDF finding aid instead of genera... Verified 01/28/2016

History

#1 Updated by José Raddaoui Marín about 4 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 about 4 years ago

  • Assignee deleted (Jesús García Crespo)

#3 Updated by Dan Gillean about 3 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 3 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 3 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 3 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 3 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 3 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 3 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 3 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 3 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 3 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.

Also available in: Atom PDF