Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-3024

"Administrator" and "Anonymous" groups can be renamed or deleted, which would cause them to no longer function in 6.x

    Details

    • Attachments:
      0
    • Comments:
      11
    • Documentation Status:
      Complete or Committed

      Description

      In previous versions of DSpace (5.x) and on master, it is possible to rename the "Administrator" and "Anonymous" group through either XMLUI or JSPUI.

      This is a serious issue, as the refactored Group class DEPENDS on these groups having very specific names:
      https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/eperson/Group.java#L33

      The most serious aspect of this is if you rename your "Administrator" group, you've essentially locked out ALL Administrative users, and the only way to change it back is via SQL queries.

      This is because the AuthorizeService.isAdmin() method depends on having a group named "Administrator":
      https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authorize/AuthorizeServiceImpl.java#L417

      So, if a site has either previously renamed the Administrator group (in 5.x), or renames it on "master", they will end up with a DSpace that has no administrative user accounts (i.e. DSpace becomes non-functional from a Administrative point of view).

      In 6.x, I think we need to do the following:

      1) First, in our 5.x->6.x Flyway migrations, we need to ENSURE the 5.x Group with ID=0 is named "Anonymous", and the 5.x Group with ID=1 is named "Administrator". Then, we can assign a new UUID to each Group, in order to make them compatible with 6.x

      2) Second, in the 6.x codebase we need to ensure these groups CANNOT be renamed. It MUST be blocked at the API layer, but we also may wish to add a new "isNameEditable()" (or similar) method/flag that UIs can use to determine whether to allow editing of the group name.

      3) Finally, we also need to ensure these groups CANNOT be deleted. (See also DS-2687, which implies we need to also ensure they cannot be accidentally removed via a DROP...CASCADE)

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mwood Mark H. Wood
                Reporter:
                tdonohue Tim Donohue
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: