feat: p/demo/accesscontrol & p/demo/timelock

[kazai777]

We have developed two packages: accesscontrol and timelock inspired by openzeppelin contracts. These packages were created in collaboration with @mous1985 , @DIGIX666 , and myself.

The accesscontrol package was primarily designed to support the development of the timelock package, but it can also be used independently for many other use cases.

Features

Accesscontrol

The accesscontrol package provides a library for managing roles and permissions within Gno. It allows for the creation, assignment, and management of roles with specific administrative privileges, ensuring that only authorized accounts can perform certain actions.

Timelock

The timelock package offers a library for scheduling, canceling, and executing time-locked operations in Gno. It ensures that operations are only carried out after a specified delay and provides mechanisms to manage and verify the status of these operations. The creation of the accesscontrol package was necessary to provide role and permission management required for the administrative tasks of timelock.

Use Cases

Accesscontrol

• Realm Administration Management: Create administrator roles to manage realms and assign or revoke roles as needed.
• Role-Based Access Control (RBAC): Implement an RBAC system to control who can access which resources and perform which actions within a Gno dApp.
• Security and Compliance: Use roles to ensure that only authorized individuals can perform critical actions, helping to meet security and compliance regulations.

Timelock

• Delayed Transactions: Schedule transactions or actions to be executed at a specific future time.
• Asset Locking: Implement asset locking mechanisms where users must wait for a certain period before they can access or move assets.
• Task Automation: Automate periodic or conditional tasks using specific time delays.

These examples of use cases are not exhaustive, and many other things are possible with these packages.

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[deelawn]

Great stuff -- looks pretty good overall. There are some things that I think need to be changed and a bunch of other comments asking questions about why something is the way it is.

[thehowl]

The limit on 30 seems kind of arbitrary for a package; more like a kind of validation that should be done, if anything, on the side of a realm (as an end-user application). But I don't expect many realms to publicly allow adding roles, anyway.

[DIGIX666]

the limit of 30 is intended to prevent someone from too overloading the chaine, for example by setting it to 1M characters. Do you think it's better to set a higher maximum or to let the user do it himself, even if this leaves open the possibility of defining a large number of characters?

[thehowl]

I would say we remove this.

• Roles is not likely to be publicly exposed in a realm, anyway.
• But if it was, exposing RenounceRole means that the Roles cannot be used for a role like banned; because the user can "renounce it".

[DIGIX666]

I know what you mean, it's true that I didn't take the case of the banned role. So it's not really safe to expose RenounceRole
Do you think it might be a good idea to keep RenounceRole but modify it for Roles defined as non-critical?
example: TestUser, TemporyUser, Guest...

[thehowl]

Can we make a case for how this is different / better than p/demo/acl?

I'm not saying it's perfect, just that demo/ should probably contain one preferred ACL implementation. We can decide to move this one to p/<name>/accesscontrol, or that one to p/nt/acl. (cc'ing also @moul for an opinion on what to do here)

[DIGIX666]

Although acl and accesscontrol may seem similar at first glance, accesscontrol stands out due to its ability to implement role hierarchies as well as dynamic permission options

[thehowl]

Can you give an example? Namely, of where this distinction is useful?

[DIGIX666]

Imagine a user can belong to several groups with different permissions. With an ACL system, each permission has to be checked individually for the user, which can become complex depending on the number of users in the group. In Accesscontrol lets you manage access via hierarchical roles (e.g. Admin, Manager, Employee): each role has specific permissions automatically applied to all its members. This simplifies authorization management and makes the system more flexible, especially for large groups

[thehowl]

I see we're using std.PrevRealm() to determine the owner and generally the "sender". This assumes there's an admin user doing management, and everyone else just following suit.

However, I think an equally possible flow is that of having a realm which has an access control list. In this case, actually, we shouldn't do any checks on PrevRealm(); the realm can just use it unexported. But I suggest you have an option for the ACL to not have a "owner"; in which case the PrevRealm checks are simply not performed. Allows someone else to compose other rules on top as well.

Btw if Roles is meant to be exposed in a realm, then its fields should be unexported.