Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AuthZ for Preservation: Ensure no one person has write access to all copies. #414

Open
rosiel opened this issue Nov 9, 2016 · 7 comments
Labels
Subject: Access Control related to managing roles and permissions/information security. Type: use case proposes a new feature or function for the software using user-first language.

Comments

@rosiel
Copy link
Member

rosiel commented Nov 9, 2016

A "a challenging, food for thought-type requirement" from Brad, as worded in The NDSA Levels of Digital Preservation, Level 4:

Title (Goal) Ensure no one person has write access to all copies.
Primary Actor Repository admin
Scope preservation, access
Level High
Story I want to comply with the The NDSA Levels of Digital Preservation, Level 4.

Source: Page 3, Table 1, Row 2 (File Fixity and Data Integrity), Level 4 definition:
http://www.digitalpreservation.gov/documents/NDSA_Levels_Archiving_2013.pdf

This is a "use case" that might involve other system aspects, such as the backups and (possibly) where else an object has been duplicated.

@ruebot ruebot added the use case label Nov 9, 2016
@ruebot
Copy link
Member

ruebot commented Nov 9, 2016

It would be helpful to flesh this out a lot more. Please expand on the level, and what layers of the stack, looking specifically at the gap between Fedora and CLAW where this would be required.

@rosiel
Copy link
Member Author

rosiel commented Nov 9, 2016

I'm sorry. I know nothing about standards for digital preservation. I tried to include a disclaimer that this is not necessarily CLAW related, but likely has more to do with the implementation of good backup policies and strategic content duplication.

My goal in including this was to bring the use cases that were brought forward in the discussion group to the appropriate venue.

Please close this ticket if this is unacceptable.

@ruebot
Copy link
Member

ruebot commented Nov 9, 2016

@rosiel what discussion group?

@dannylamb
Copy link
Contributor

So no admin user, then? Or just block admin user from having admin privileges, thus rendering it not admin?

@rosiel
Copy link
Member Author

rosiel commented Nov 9, 2016

From here: https://groups.google.com/forum/#!topic/islandora/YGBMUU4OSM8

As mentioned it was "a challenging food for thought" requirement.

We've always managed one single copy of an archival object, maybe this points out a use case where multiple would be worthwhile?

@ruebot
Copy link
Member

ruebot commented Nov 9, 2016

I think this would be an excellent opportunity for the group to articulate where they would like to see the functionality for the management of multiple copies of an archival object to reside; Drupal, Fedora, somewhere else?

@kstapelfeldt kstapelfeldt added Type: use case proposes a new feature or function for the software using user-first language. Subject: Access Control related to managing roles and permissions/information security. and removed use case labels Sep 25, 2021
@kstapelfeldt
Copy link
Member

Maybe I'm missing something, but this seems like a staffing/practice problem? Without two systems administrators, how would software solve this problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Subject: Access Control related to managing roles and permissions/information security. Type: use case proposes a new feature or function for the software using user-first language.
Projects
Development

No branches or pull requests

4 participants