Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-26972

Granting "Administer platform" on a user or group creates unwanted permissions



    • Type: Bug
    • Status: Closed
    • Resolution: Deferred
    • Affects Version/s: 7.27.3, 7.29.3, 7.33.6
    • Fix Version/s: None
    • Component/s: Access, permissions
    • Labels:



      Since Artifactory v7.27.3 at least, granting "Administer platform" to a user or a group through both UI or API also generates strange permissions.
      Those permissions are:

      • Invisible on the UI, except on the Security Descriptor, but they cannot be updated or deleted.
      • Accessible through the API, but trying to delete them throws a 500 Internal Error, with a generic message:
        "errors" : [ { "status" : 500, "message" : "Could not delete permission INTERNAL_default:DEV:Project Admin:REPO with identifier INTERNAL_default:DEV:Project Admin:REPO" }


      If the user(s) or group(s) are no longer granted the "Administer platform" right (through user/group update or deletion), the permissions disappear.

      The names are constant over each adding or removal of "Administer platform" right, and are the following:

      • INTERNAL_default:DEV:Project Admin:REPO
      • INTERNAL_default:DEV:Project Admin:REPO:shared
      • INTERNAL_default:DEV:Project Admin:REPO:shared:read
      • INTERNAL_default:PROD:Project Admin:REPO
      • INTERNAL_default:PROD:Project Admin:REPO:shared
      • INTERNAL_default:PROD:Project Admin:REPO:shared:read

      I checked JFrog Confluence pages about this behavior and it is not documented anywhere.


      Those permissions are side effects of the "Administer platform" right attribution and should not be created at all.
      If it is now an intended mechanism, then it should be documented.


      We are Artifactory Pro users for several years (4+). We have been using Artifactory to host our binaries, documentation and caching public repositories since then.
      We are sure that on v7.18.7, the issue was not present as a user had been promoted and the permissions did not appear.
      For v7.25.5, we are unsure of the behavior.
      This behavior has been spotted first on v7.27.3, but since the user promotion was irrelevant, we reverted it and the permissions disappeared.
      We used v7.29.2 also but this use case did not happen during its exploitation.
      2 weeks ago on v7.33.12, we noticed it again and as user promotion was irrelevant once more, we noticed the same behavior (permissions removed after user was demoted).
      Last week, it happened again but since this time the user promotion is valid, we have those lingering permissions and we need to know how they should be considered.

      Thanks in advance for your support.




              Gregoonet Gregory GEORGES
              0 Vote for this issue
              1 Start watching this issue