Access to Memory (AtoM)

What are you trying to achieve? I read the description of the ticket but I couldn't figure out what's the problem, sorry!

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 ...

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.

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.

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?

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.

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.