Token init instructions don't check if accounts are signers

[jstarry]

Problem

A bad client might issue the "create account" and "init mint" in separate transactions. An attacker could front run and initialize the mint with themselves as owner and the original creator might not realize this. Then, the attacker could mint tokens whenever they please

This is applies to init multisig and init token account as well

Suggested Fix

Reject init instructions if initialized account is not a signer

[mvines]

I think this is something we just need to well document and get 100% in every sdk/example we produce instead of fixing in code. Vote/Stake accounts are the same way. Requiring a signed init instruction means that we either can't support derived accounts, or need Initialize...WithSeed variants.

[jackcmay]

I've already updated the js bindings to do the "create account" and "init mint" instruction in the same transaction.

@jstarry Anything more on this issue?

[jstarry]

Great, I think we could keep this as a reminder when writing documentation for the token library? Otherwise, nothing to do

[jackcmay]

@mvines I'm having second thoughts about this, can you elaborate on how we can't support derived accounts? If you are referring to derived program addresses then the program will be the signer and can sign the init instruction. If not will token us account derived with seed?

[mvines]

I'm having second thoughts about this,

What's your concern specifically?

If I use SystemInstruction::CreateAccountWithSeed to create my Mint or Account account, I can't sign with the account address's private key because there is none. That's the simplest case that I think we lose if we require the account be a signer on initialize.

[jackcmay]

Yeah, guess I didn't really see that as a use case

[mvines]

It's super useful! For example I used it in stake-o-matic for example to easily keep track of the various stake accounts that are associated with each validator