Skip to first unread message

FEDESOFT S.L.U.

unread,
Nov 6, 2023, 7:24:52 AM11/6/23
to AtoM Users
Hello everyone,

After consulting the documentation and reviewing similar questions regarding permissions and PREMIS rights I'd like to illustrate my question with the following example:

Admin
  • A simple archival description has been created:
    • Fonds > Series > File/Item (digital object import, i.e. document.pdf)
  • Group > anonymous > All archival description:
    • All options are set to deny, except for 'read,' which is granted.
  • All premis act > Disallow permissions 
    • Master, Reference and Thumb -> uncheked
  • document.pdf > create new rights > Act/granted rights
    • Discover, display, replicate -> Disallow

Anonymous User
  • Can read the archival description and the pdf is displayed as in the following image:
document_example_anonymous.png



Everything is correct and as expected, accessing as admin or another user with permissions to view the document generates a url similar to the following:

https://domain.test/uploads/r/null/0/9/e/<long-hex-code>/document.pdf?token=<long-hex-code>

However, with that url, any other anonymous user can view the document. Is that the correct behaviour when the file is a text media type? that is, anyone can access if the url is provided.

version: 2.7.3 - 192

Thank you in advance for your help.


Dan Gillean

unread,
Nov 6, 2023, 2:36:13 PM11/6/23
to ica-ato...@googlegroups.com
Hi there, 

This could certainly be improved, but it is an edge case that applies only to PDFs. 

PDFs are the one exception to the various Permissions rules in AtoM to deny access to the master digital object. This was hardcoded early on in the application as a sort of workaround - in general. if you are adding PDFs to your public-facing catalog, you want users to read any text that might be found in the PDF. However, the reference image generated from PDFs is a JPG that is generally just the first page, and too small to be readable. For that reason, early ICA-AtoM developers decided that, rather than adding custom rules just for PDFs, they would hard-code an exception for digital objects identified as PDFs so that AtoM won't apply the usual permission restrictions. This allows users to still restrict access to other digital object masters using the permission settings, without rendering the PDFs completely unusable.

This is also part of the reason that we use hashing when determining the digital object directory structure and final path to the master - to help obfuscate it. To be able to access a PDF as a public user that has been restricted as you have done, you need someone with access to the master digital object to give you the URL directly - it would take a lot of effort to brute force that link, and random guessing alone will not do it. 

This means that the security risk is human - an insider with access helping to violate the established permissions by navigating to the master object, copying the URL, and giving it to someone who cannot log in themselves. We could certainly look to improve this in the future and ensure that the master PDF is fully restricted when there are also PREMIS Rights applied, etc - but in this theoretical security breach, why wouldn't the insider simply share their login credentials, or download the PDF themselves and give it to the public user, or help in some other way, etc...?

In any case: though low risk, I do agree that this should be fixed. While hardcoding the permissions to allow for the PDF exclusion is understandable (if not ideal) from an historical development perspective, it would be good to patch the case where specific restrictions via PREMIS Rights are applied, as this should not have the same exception. 

I would also personally love to see the hard-coded rule about PDFs and permissions changed to a user-configurable global setting, as this seems a manageable compromise between the complexity of adding even more granular permissions to an already-overloaded module in AtoM needing an overhaul, and doing nothing. This would allow users with particularly strict security requirements to consistently enforce the digital object permissions for all object types, while still allowing others who want to configure permissions globally but still allow PDFs to be readable to maintain their current configurations. 

In the short term, I have let our Maintainers know about this edge case, so they can determine how they would like to proceed. 

Cheers, 
 
Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory
he / him


--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/55a1b343-dbd5-45c8-bfc6-72d32821a859n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages