RFC - Refine Trigger Authority Mechanism #14
Conversation
0x009922
force-pushed
the
trigger-authority
branch
from
d0b612d to
2b640ff
Compare
Signed-off-by: quacumque <[email protected]>
0x009922
force-pushed
the
trigger-authority
branch
from
2b640ff to
81b3be2
Compare
|
|
||
| ### Option 2 - Mixed model | ||
|
|
||
| - Provide an ability to set whether a trigger should use a **pre-defined authority** or the **caller's** authority. |
There was a problem hiding this comment.
Is it specified in the trigger definition at the time of creation, or is it set when the trigger is executed?
There was a problem hiding this comment.
Same as now - defined at the time of registration, once.
There was a problem hiding this comment.
Only things that are mutable in triggers (after registration) are their:
- Metadata
- Remaining repetition amount
| | Trigger Kind | Trigger execution authority | | ||
| | -------------------------------------------------------------------------- | ------------------------------------------------------------ | | ||
| | Pipeline | Use trigger's | | ||
| | Time | Use trigger's | | ||
| | Trigger completed | Use trigger's | | ||
| | Data | Use caller's (the one who caused the data event) | | ||
| | By-call | Use caller's (who executed the `ExecuteTrigger` instruction) | | ||
| | Also, if any of the data triggers fail, the entire transaction also fails. | | |
There was a problem hiding this comment.
In my view, the only clearly useful programmable execution systems currently identified are the following three:
- smart contract (integrated with by-call trigger and custom instruction)
- data trigger
- time trigger
I am skeptical about providing other types of triggers. For details, see hyperledger-iroha/iroha#5512.
| ### Use case 2 | ||
|
|
||
| I (e.g. Alice) want to deploy a data trigger that reacts on someone else's (e.g. Bob's) asset balance change. This | ||
| trigger would, for example, make a transfer on _my_ behalf. | ||
|
|
||
| However, when Bob changes his own balance, my trigger would be executed with _Bob's_ permissions, not mine, and | ||
| therefore the trigger will fail to make the intended transfer. |
There was a problem hiding this comment.
As an alternative, Alice could keep a multisig proposal pending and have it approved by a data trigger, which would achieve the same effect.
There was a problem hiding this comment.
Doesn't it sound kind of complicated?
There was a problem hiding this comment.
Yes, it may sound more complex — but that complexity allows us to avoid introducing fixed authorities and implicit privilege escalation. There is a clear trade-off here:
- On one side, fixed-authority triggers look simple, but they open the door to confused-deputy problems and unintended elevation.
- On the other, approaches like multisig, time triggers, or other two-phase commit flows are somewhat more complex, but they keep the execution model consistent and auditable, with no hidden authority switches.
In a security-critical system like Iroha, it is better to accept a bit more design complexity than to adopt a mechanism that weakens the permission model.
| ## Consideration: triggers are a part of transaction? | ||
|
|
||
| Currently, data triggers are a part of the original transaction, and if data trigger fails - the entire transaction | ||
| fails. | ||
|
|
||
| This seems to be useful in some cases, but is not compatible with the case when Data trigger has a pre-defined | ||
| authority: Alice then could fail Bob's transactions if she wants. However, it may also be desirable: an admin may want | ||
| to fail someone's transaction by their data trigger. |
There was a problem hiding this comment.
The control of whether someone’s transaction succeeds or fails should be centralized in the permission system.
There was a problem hiding this comment.
Why?
Permission system allows for fine-grained access to resources and actions. I am not sure I understand why it should be centralized.
There was a problem hiding this comment.
The key issue is that the entity subscribing to an event is not necessarily the legitimate administrator.
Any third party who has permission to listen to even a single event along the execution path can force the entire transaction to fail.
And of course, such a malicious actor would never register their sabotage trigger in a detached mode — they would configure it specifically so that it always propagates failure.
There was a problem hiding this comment.
And of course, such a malicious actor would never register their sabotage trigger in a detached mode — they would configure it specifically so that it always propagates failure.
Yes, this makes total sense to me. Of course, if we introduce "attached/detached" modes, it would be essential to make attaching a trigger also guarded by a permission.
There was a problem hiding this comment.
Historically, the permission system only governed state read/write access.
Once we bring attach/detach into scope, the permission model must also cover a second dimension: transaction scope control (propagation reach and generational boundaries):
- Dimension 1: State Access (read/write capabilities)
- Dimension 2: Scope Control (changing the propagation surface via attach/detach)
| ## Security Considerations | ||
|
|
||
| - Risk of privilege escalation if trigger logic is careless | ||
| - Need to treat triggers with pre-defined authority as “contracts” that must validate caller input | ||
| - Possible DoS if malicious actors span triggers with invalid inputs |
There was a problem hiding this comment.
In general, fixing the authority of a data trigger means forcing a complete simulation of the event source at registration time, which can sometimes be difficult and, in my view, opens the door to unfortunate accidents.
There was a problem hiding this comment.
forcing a complete simulation of the event source at registration time
Could you elaborate, please?
There was a problem hiding this comment.
Fixing the authority of a data trigger effectively means that causing the trigger event is equivalent to acquiring that authority. As a result, the trigger author must design the subscription with extreme care to ensure that no unintended path can fire it.
3 participants
No description provided.