2

I ask myself, why this extrinsic (https://github.com/paritytech/substrate/blob/e9b0facf70eeb08032cc7e83548c62f0b4a24bb1/frame/sudo/src/lib.rs#L224-L263) exists? I mean the sudo key could execute any transaction from any account, although the sudo user might not have the private key of this account.

When I would like to stop this dispatch from being executed, I could use the transaction filter, right?

1 Answer 1

2

Yes Sudo::sudo_as can be used to impersonate any other account of type Signed whereas Sudo::sudo provides Root.

When I would like to stop this dispatch from being executed, I could use the transaction filter, right?

No. You cannot rely on such simple assumptions about how pallets interact. It gives of a false sense of security while (in most cases) not even archieving what you want. Once someone acquires Root, through Sudo or other, they can do anything.

In your case it would indeed hinder direct dispatches to Sudo::sudo_as, but Root (acquired through Sudo::sudo) has many ways to hack around that. The obvious like Utility::dispatch_as and the more mischievous being System::set_code.

1
  • Is there any existing pallet, which has less power than the sudo pallet, but without token holder votes like in the democracy pallet. So I am searching for a pallet, which has a privileged account, that can do runtime upgrades, but only after a long review period these upgrades get enacted.
    – Chralt
    Jan 13 at 5:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.