Permalink
Browse files

Merge branch 'master' of github.com:aragon/aragon-wiki

  • Loading branch information...
Smokyish committed Nov 10, 2017
2 parents 0523098 + 4743814 commit c3a734c651a04052cea0dc80753079a4a6a9ab82
Showing with 11 additions and 9 deletions.
  1. +9 −9 docs/dev/AragonOS.md
  2. +2 −0 docs/dev/apps/finance.md
@@ -63,7 +63,7 @@ In order for an Entity _A_ to be able to `grantPermission` that **allows** Entit

1. Entity _A_ must already have permission _P_ to perform role _X_ actions.
2. Entity _A_ must be it’s own permission parent _Pa_ for permission _P_.
3. Entity _B_ does not have any permission to perform role _X_ actions (avoids being able to takeover as parent).
3. Entity _B_ does have permission to perform actions of role _X_ (avoids Entity _A_ being able to takeover as parent by Entity _B_).

When setting a Permission _P_, the one granting the permission can specify the Entity that will be the parent for _P_:

@@ -95,7 +95,7 @@ kernel.createPermission(address entity, address app, bytes32 role, address paren

This call is mostly identical to `grantPermission`, with the exception that it allows the creation of a new permission from scratch if it doesn’t yet exist.

The `createPermission` action needs to be protected by the ACL with a role. It is an important function that could be used in malicious ways. When the Kernel is instantiated, it will also create the permission for an address to create new permissions.
The `createPermission` action needs to be protected by the ACL with a role. It is an important function that could be used in malicious ways. When the Kernel is initialized, it creates the permission for an address to create new permissions.

If the ACL is checked for a permission that hasn’t been created yet, the ACL won’t allow the action to be performed by default.

@@ -110,18 +110,18 @@ PermissionSet(address from, bytes32 role, address to, address parent, bool allow
As an example, the following shows a complete flow for user Root to create a new DAO that has the basic permissions set so a Voting app could manage funds in a Vault app:

1. Deploy the Kernel
2. Performing `kernel.instantiate(rootAddress)` creates the following permission under the hood:
`createPermission(rootAddress, PERMISSIONS_CREATOR_ROLE, kernelAddress, rootAddress)`
2. Performing `kernel.initialize(rootAddress)` creates the following permission under the hood:
`createPermission(rootAddress, kernelAddress, PERMISSIONS_CREATOR_ROLE, rootAddress)`
3. Deploy the Voting app
4. Make it so that the Voting app can call `createPermission`:
`createPermission(votingAppAddress, PERMISSIONS_CREATOR_ROLE, kernelAddress, votingAppAddress)`
`grantPermission(votingAppAddress, PERMISSIONS_CREATOR_ROLE, kernelAddress, votingAppAddress)` (has to be executed by `rootAddress`)
5. Deploy the Vault app, which has a signature called `transferTokens`
6. Create a new vote to create the `TRANSFER_TOKENS_ROLE` permission
`createPermission(votingAppAddress, TRANSFER_TOKENS_ROLE, vaultAppAddress, votingAppAddress)`
`createPermission(votingAppAddress, vaultAppAddress, TRANSFER_TOKENS_ROLE, votingAppAddress)`
7. If vote passes, the Voting app can then call `TRANSFER_TOKENS_ROLE` actions, which in this case is just `transferTokens` in the Vault
8. Votes can be created to transfer funds

An initial implementation of the explained ACL can be found in [aragon-core’s Kernel](https://github.com/aragon/aragon-core/blob/dev/contracts/kernel/Kernel.sol) file.
An implementation of the explained ACL can be found in [aragon-core’s Kernel](https://github.com/aragon/aragon-core/blob/dev/contracts/kernel/Kernel.sol) file.

#### Checking Permissions

@@ -133,8 +133,8 @@ Consider kernel **K**, an entity **E**_0_ and an app **A**. **E** wants to perfo
The client should know that **E**_0_ cannot directly call **A**_sig_, as it doesn’t have that role, but that a list of Entities [**E**_1_, **E**_2_] do have that role on app **A**. The client should then show the user the multiple possible forwarding paths to pass the call to **E**_1_, so then **E**_0_ could perform **A**_sig_.
Calculating a forwarding path requires knowing what Forwarders entity **E**_0_ can perform actions through.
The user or contract performing this action could then choose their preferred route to scale permissions in order to perform **A**_sig_. For example, **E**_1_ may be a Voting app **V**, so the action would be to create a new vote that, in case of being approved, would call **A**_sig_. Since **V** has role **A**_role_ it has permission to execute **A**_sig_, therefore we would have successfully completed a permission escalation.
Note that permission escalation can occur automatically or it can be delayed and require further action by other entities like in the case of the voting app.
The user or contract performing this action could then choose their preferred route to forward permissions in order to perform **A**_sig_. For example, **E**_1_ may be a Voting app **V**, so the action would be to create a new vote that, in case of being approved, would call **A**_sig_. Since **V** has role **A**_role_ it has permission to execute **A**_sig_, therefore we would have successfully completed a permission escalation.
Note that permission escalation can occur instantly or it can be delayed and require further action by other entities like in the case of the voting app.
<center><img src="../../images/aragonos/permission_escalation.png"></center>
@@ -85,6 +85,8 @@ In case a payment can already be executed on creation, it will be executed.

If a payment is created that won't be repeated ever again, and already was executed, only an outgoing transaction is recorded to save storage.

A payment can have a past **initial payment time**, which could cause many instances of the recurring payment to be executed at payment creation time.

#### Executing payment
```
finance.executePayment(uint256 _paymentId)

0 comments on commit c3a734c

Please sign in to comment.