You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, when I deploy an AccessManaged contract and use the restricted modifier, it automatically gives the admin role the permission to call it (since getTargetFunctionRole() will return 0, which is the admin role).
I think that can lead to situations where projects can give the admin role too much power without explicitly declaring it through setTargetFunctionRole, by messing up a deploy script for example (with AccessControl, onlyRole was more explicit about which role protects the method).
Why is this the behavior, instead of reverting if not explicitly set?
The text was updated successfully, but these errors were encountered:
The intention of the manager is to provide a way to progressively decentralize a protocol, so deploying is like the very first step where things are still in deployer's control. Next steps would be to assign permissions and finally renounce its own admin role.
I agree granting the admin role to the deployer may be dangerous, but it's designed so that configuration of the manager can be done within the same account and finally renounce the ownership.
Right now, when I deploy an
AccessManaged
contract and use therestricted
modifier, it automatically gives the admin role the permission to call it (sincegetTargetFunctionRole()
will return 0, which is the admin role).I think that can lead to situations where projects can give the admin role too much power without explicitly declaring it through
setTargetFunctionRole
, by messing up a deploy script for example (withAccessControl
,onlyRole
was more explicit about which role protects the method).Why is this the behavior, instead of reverting if not explicitly set?
The text was updated successfully, but these errors were encountered: