NNS power over arbitrary canisters

Developers
1

During yesterday’s public Global R&D meeting, there was discussion on the chat about what kind of powers the NNS has over arbitrary canisters on the Internet Computer. There were some misunderstandings about the extent of the NNS powers so I hope that with this post we clarify things and spread a better understanding of how things work among the community.

Background

On the Internet Computer there is the management canister which allows users and other canisters to manage (e.g. upgrade or stop or even uninstall) a canister that they are a controller of. The IC enforces that only a controller is able to perform these operations, for example here’s the check that happens for install_code requests.

NNS controlling other canisters

It is possible to have a canister be controlled by the NNS and therefore have its upgrades go through proposals that the IC community can vote on. The idea is simple: a canister needs to assign the NNS root canister as its controller and at that point the canister is under the control of the NNS and therefore can be upgraded through proposals like this one.

If the NNS root canister is not explicitly added as a controller of the target canister, then an attempt to upgrade the canister originating from the NNS would fail, since the controller check that was mentioned in the “Background” section will fail. For the NNS canisters the same controller checks apply as for any other canister. There is only one exception to this rule: uninstall_code can be called by the NNS on a canister even if NNS is not its controller. This can only be done via a proposal and is possible due to an explicit exception that allows the Governance canister to uninstall any canister on the IC. This exception was introduced to give the NNS the ability to remove highly undesirable content from the Internet Computer via proposals.

To summarize, the NNS canisters do not have any special privileges to manipulate other canisters except that they can uninstall a canister (which can only happen via a proposal).

cc @lastmjs who was involved in the zoom chat yesterday (please feel free to ping others who might have had wrong assumptions about this topic).

8 Likes
2

It should be noted that, although highly unlikely, a replica upgrade could induce hard-coded deployments to canisters that do not go through other NNS avenues. Of course, the replica upgrade itself is an NNS proposal, so we need to get better at the validation of the replica code. (Please correct me if I am misspeaking…there may be other limitations to replica size, etc that reduce this possibility).

5 Likes
3

@skilesare You are right. Indeed, someone could propose a replica upgrade that performs any arbitrary task you might think (including hardcoded deployments of canisters). As you also point out, this would be a proposal as well that would need to be adopted by the IC community. I would consider this highly unlikely as you mentioned yourself.

so we need to get better at the validation of the replica code

100% agreed. I think we (as the IC community) all agree that we need better decentralization when it comes to replica upgrades validation. And, afaik, there are efforts working towards this long term goal.

5 Likes