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

Add a bool return to _grantRole and _revokeRole #4241

Merged

Conversation

Amxx
Copy link
Collaborator

@Amxx Amxx commented May 11, 2023

Similarly to EnumerableSet's add and remove, I believe AccessControl's _grantRole and _revokeRole should return a boolean value. This would help overrides version handle no-ops.

I believe the public versions should not return the boolean, but that is open to discussion.

PR Checklist

  • Tests
  • Documentation
  • Changeset entry (run npx changeset add)

@changeset-bot
Copy link

changeset-bot bot commented May 11, 2023

🦋 Changeset detected

Latest commit: 7dc7e62

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
openzeppelin-solidity Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@Amxx Amxx changed the base branch from master to next-v5.0 May 11, 2023 08:28
@socket-security
Copy link

socket-security bot commented May 11, 2023

No dependency changes detected. Learn more about Socket for GitHub ↗︎

👍 No dependency changes detected in pull request

@frangio
Copy link
Contributor

frangio commented May 17, 2023

This would need to be rebased. However, I would also like us to consider the alternative of making the functions revert in the cases where they would return false, as an alternative to adding a return value.

The argument so far has been that we want to allow no-ops, but we've seen how in this case it can actually lead to bugs when you override the function, and you very easily assume that there is an actual revoke ongoing. I think this is stronger for revoke than it is for grant.

@Amxx Amxx force-pushed the improve/AccessControl/internal-return-bool branch from 196ebe3 to c41f431 Compare May 17, 2023 07:35
@Amxx Amxx added this to the 5.0 milestone Jul 6, 2023
@Amxx
Copy link
Collaborator Author

Amxx commented Jul 6, 2023

@frangio @ernestognw

This got lost, I think we should do it in 5.0

@ernestognw ernestognw changed the base branch from next-v5.0 to master July 6, 2023 19:30
contracts/access/AccessControlEnumerable.sol Outdated Show resolved Hide resolved
contracts/access/AccessControlEnumerable.sol Outdated Show resolved Hide resolved
contracts/access/AccessControl.sol Show resolved Hide resolved
contracts/access/AccessControl.sol Show resolved Hide resolved
@ernestognw
Copy link
Member

ernestognw commented Jul 6, 2023

I'd like to consider this change for 5.0, but we didn't address @frangio's comments.

I would also like us to consider the alternative of making the functions revert in the cases where they would return false, as an alternative to adding a return value.

Sounds like a good idea but it'll require us to check how it behaves with AccessControl extensions. For example, AccessControlDefaultAdminRules does a _revokeRole and _grantRole together in _acceptDefaultAdminTransfer because it assumes no-reverts. If a user extends the contract to add an alternative mechanism for revoking the DEFAULT_ADMIN_ROLE after a change was scheduled via beginDefaultAdminTransfer, there won't be way of accepting the role anymore.

imo we don't have time to check for those cases if we decide to do reverts. I'm more in favor of the current PR proposal.

@ernestognw
Copy link
Member

btw, should we add tests for the internal function return values?

@Amxx
Copy link
Collaborator Author

Amxx commented Jul 7, 2023

btw, should we add tests for the internal function return values?

Added

Amxx and others added 2 commits July 7, 2023 17:21
Co-authored-by: Ernesto García <ernestognw@gmail.com>
@Amxx Amxx requested a review from ernestognw July 31, 2023 19:54
@Amxx
Copy link
Collaborator Author

Amxx commented Jul 31, 2023

@frangio @ernestognw

@frangio
Copy link
Contributor

frangio commented Jul 31, 2023

However, I would also like us to consider the alternative of making the functions revert in the cases where they would return false, as an alternative to adding a return value.

Following up on this question. Our current thinking is that if these functions reverted, it would be possible to frontrun a batch of revokeRole operations with a single renounceRole and cause the entire batch to fail, which doesn't seem good either.

If the concern is that revokeRole may appear to succeed when no roles have been revoked, the recommendation should be to check the transaction events to confirm the desired end result.

We should write this in the contract.

@frangio frangio closed this Jul 31, 2023
@frangio frangio reopened this Jul 31, 2023
Copy link
Member

@ernestognw ernestognw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but we also discussed making TimelockController return the proposalId, I'd like to merge this and add that in another PR if it's not already out there.

@Amxx
Copy link
Collaborator Author

Amxx commented Aug 1, 2023

LGTM but we also discussed making TimelockController return the proposalId, I'd like to merge this and add that in another PR if it's not already out there.

In TimelockController I was talking about public function. Changing the return type of public functions is an issue because of composability. If the new implementations of TimelockController return the proposalId when doing propose, would we use that return value in the Governor modules ? If yes, then the module would not be compatible with pre-existing instances.

This was referenced Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants