OZ5 AccessManager - Does it support freeze?

Support Contracts
1

In the OZ 5's new AccessManager, Is it possible to freeze the role ?

Assume there's a contract:

contract Voting {
    function test() public restricted() {

   }
}

It's been set up so that this function can be called by EntityA. Though, since there're admin roles and the function setRoleAdmin, it's possible that Admin or PM can give the same role that allows calling test function to EntityB.

Is it possible that in accessManager, something can be called such that nobody(not even admin) will ever be able to give test function permission to anyone ever ? as in, freeze this function on Voting Contract ?

Unfortunatelly, I couldn't figure this out. Even if setTargetFunctionRole is assigned a 2000years delay, admin can still call setAdminRole, change the role admin and that new role admin can still grant the same permission to others. It's horrible to use execution delay the caller may have because if there're 2 admins, I really don't want to set 2000years execution delay for the admins as this could make things harder - what if it should be possible to set role admin for other roles that don't need freezing ?

Any idea ? Maybe OZ 5 doesn't support this ?

1 Like
2

Hello @Giorgi_Lagidze

An option for you is to set

  • the grantDelay of the role that can call your function to a very high value.
  • the adminDelay of the target to a very high value.

That way

  • the admin will still be able to grant the role, but the role will only be effective after a super long delay
  • the admin not be able to change the role allowed to call your target to something that can be granted faster.

With these two, you are not freezing indefinitelly, but you can make any change take years (max delay is ~136 years).

1 Like
3

Be carefull that if you do that, and if the accounts that are authorized gets lost, of compromised, you'll have no solution.

4

Thank you for answering. @Amxx Though, there're a couple of problems.

  1. Assume that 3 people hold roleId = 2 and this roleId is attached to contractA's test function. Even if setGrantDelay and setAdminDelay is called, that won't freeze roleId = 2. This is because those 3 people that already have this role still continue successfully to call test function. You are obliged to also call grantDelay for each of these 3 persons so that they also use the new delay which is not super elegant.
  2. As far as I understand, calling setGrantDelay for the specific role is not enough, because super admin can still call it again with smaller value and revert what he did. I think the only solution is to also call setGrantDelay with the ADMIN_ROLE so that admin can no longer call setGrantDelay, but then this completely freezes the whole system, not just the specific role, so I don't think your 2 suggestions would make it work. Could you elaborate ?
1 Like
5

I'm not sure what you mean. There is no grantDelay function. You have to grant the roleId to the 3 addreses BEFORE you setGrantDelay for roleId = 2, but afaik that is all.

Also, the grantDelay is something that applies to a role, not to a user.
Example:

I have role 0, I want to give you role 1, we assume that role 1 is administered by role 0, so as a holder of role 0, I can indeed grant you role 1.

  • If I have an execution delay attached to role 0, I need to schedule the grant operation, and wait for the delay to pass. If I have no execution delay, then I can do the grant operation immediatly.
  • When the grant operation is performed, then the system will lookup the grand delay for role 1. If there is a grant delay for role 1, then your membership in role 1 is not active yet, and you'll have to wait.

Here, the grantDelay is not a property of me (the admin that grants you role 1), but a property of role 1 itself. There is no admin power that allows me (or anyone) to give you role 1 faster than grant delay. Even if I want to update the grant delay of role 1 (to reduce it), that update is iteself affected by the original delay.

6

I think there is a confusion here:

  • someone that as the role cannot grant the role he/she has. Only an admin can do that.
  • in order to grant a role, the admin calls the public grantRole. This then calls the internal _grantRole using getRoleGrantDelay for that role. No admin are not able to buypass the grantDelay (that is the whole point).