RFC: advanced SC access rights

[damip]

RFC: advanced SC access rights

General idea

Currently, smart contracts can write on:

• the address on top of the execution stack
• addresses created previously at the current stack state

This RFC proposes solutions to achieve finer control over access rights.

Proposed additions

Right delegation on calls

Modify the call ABI to add the following OPTIONAL parameter:

access_add = [addr1, addr2, ...]

This parameter adds extra write access rights to the called SC (the called SC still has implicit write rights on itself) on the listed addresses.
The call fails if the caller doesn't have write access to the listed addresses.

List access rights

Since this RFC allows smart contracts to inherit extra rights, they need to be able to list them in order to pre-check for proper access right delegation.

Add an ABI allowing a smart contract to list the addresses on which it has write access:

access_list() -> [addr1, addr2, ....]

Removing access rights

Add the following ABI:

access_remove([addr1, addr2...])

that drops write access to a list of addresses at this call stack level.
Note that the list can include the smart contract itself !

This is used for security, in order to provably lose an access right.

[gregLibert]

@damip my understanding is that only write access to the entire datastore of the address is handled by this RFC.

Is it planned to :

• expand it to DROP (empty storage) or GRANT (delegate access right to someone else) ?
• extend the concept to key (row) instead of the entire datastore (insert, append, delete a specific key) ?

Some use cases:

• Using DROP, I can clean an old address and release all its linked storage at once.
• Using GRANT, I can delegate my storage to my CTO and he can create access to internal/external entities without needing to get my private key.
• Using a finer level of access rights and as a professional needing a weebsite, I can give insert/append/delete access to the key website to the external entity that is creating my website.
• Using a finer level of access rights and as a DNS on-chain provider I can give full access to the key .massa to the massa team.
• Using a finer level of access rights and as a swap provider, I can remove my full access rights to the key website, making it immutable but keeping everything else.

[AurelienFT]

This parameter adds extra write access rights to the called SC (the called SC still has implicit write rights on itself) on the listed addresses.
The call fails if the caller doesn't have write access to the listed addresses.

Why the SC just have access to all the addresses the called have access by default so that we don't have to specify
addresses etc.. I find it more useful to use.

[qdrn]

Removing access rights

Add the following ABI:

access_remove([addr1, addr2...])

that drops write access to a list of addresses at this call stack level. Note that the list can include the smart contract itself !

This is used for security, in order to provably lose an access right.

To do that you would have to add this call at the top of every externally called function, right ? In that case I would probably find it better to use more involved access right at the account level (using account numbers or registered names...).

[damip]

Removing access rights

Add the following ABI:

access_remove([addr1, addr2...])

that drops write access to a list of addresses at this call stack level. Note that the list can include the smart contract itself !
This is used for security, in order to provably lose an access right.

To do that you would have to add this call at the top of every externally called function, right ? In that case I would probably find it better to use more involved access right at the account level (using account numbers or registered names...).

Yes, that's the idea for access_remove.

I think that both approaches are useful:

• runtime call-wise rights delegation as described in this RFC
• stored account access rights as you are mentioning

Would be interesting to write an RFC on stored account rights