Auth: Account contract errors impersonate the contract being called

[leighmcculloch]

While playing around with enforced auth in the SDK I've noticed that when triggering error conditions in built-in contracts, the debug logs indicate a "contract error" has occurred, which is confusing because it isn't clear what contract has generated the error.

For example, in my contract I've called require_auth on a Stellar account, and when I triggered an error, I'm seeing these debug events:

HostError
Value: Status(ContractError(5))

Debug events (newest first):
   0: "Debug escalating error '' to panic"
   1: "Debug contract call invocation resulted in error Status(ContractError(5))"
   2: "Debug caught panic from contract function 'Symbol(add)', propagating escalated error 'Status(ContractError(5))'"
   3: "Debug escalating error '' to panic"
   4: "Debug incompatible signature format"

It seems like this is happening, because the Value: Status(ContractError(5)) indicates the error has made it up to the top-level, even though it was a sub-invocation that generated that contract error.

Errors from one contract shouldn't be propagated, they should become generic traps in the next contract up the stack. This is especially true of ContractErrors. When we propogate contract errors we risk a user/developer interpreting the value as having meaning defined by a contract that didn't generate the error.

In this case 5 means AuthenticationError in the context of the account contract:

rs-soroban-env/soroban-env-host/src/native_contract/contract_error.rs

Lines 8 to 14 in 352487c

	pub enum ContractError {
	InternalError = 1,
	OperationNotSupportedError = 2,
	AlreadyInitializedError = 3,
	UnauthorizedError = 4,
	AuthenticationError = 5,

But in the calling contract 5 might mean something else.

cc @graydon @dmkozh @sisuresh

[leighmcculloch]

I separated the issue of ambiguous debug events into a separate issue: #772.

[leighmcculloch]

I've updated the issue title to Account contract errors impersonate the contract being called, because I'm seeing the same behavior when using a custom account contract, and the primary issue is the issue of impersonation. It is possible for someone using a custom account contract to impersonate a contract being called and essentially MITM between two contracts.