Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add validation preventing caller PDA to be garbage-collected #386

Merged
merged 1 commit into from
Dec 19, 2024

Conversation

toblich
Copy link
Contributor

@toblich toblich commented Dec 18, 2024

No description provided.

@toblich toblich requested a review from a team as a code owner December 18, 2024 18:45
Copy link

Metric fix/accidental-caller-pda-closing main
Coverage 76.8% 76.7%

@@ -90,6 +90,12 @@ pub fn wrap_native_sol<'info>(
amount: u64,
signer_bump: u8,
) -> Result<()> {
require!(
// guarantee that if caller is a PDA it won't get garbage-collected
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be incorrect to check this always? Even if not a PDA?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH, it likely doesn't matter. My personal take is that yes, it would be incorrect, though the impact of it is likely very small.

The rent exemption only matters when accounts hold data. When the owner of that account withdraws all funds, leaving it with a 0 balance, the account is closed and the data is removed. This check aims to prevent that.

However, if the caller does not hold any data (e.g. it is just a wallet), then there is no reason to prevent them spending their last lamports in invoking ccip_send. Technically speaking, the check about the system program owning it is not exactly the same as checking whether the account holds data, as it is possible to have dataless PDAs, but it is close enough for an edge case and should still protect agains all actual "dataful" accounts being closed (even if we're failing in a corner case for a dataless PDA when we shouldn't).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. Agree. There's still a chance that the user's account is closed after calling ccip_send and some one else then gets ownership of the same account. Anyways, that's the same behavior that transferring tokens has, so not a concern.

@@ -2785,7 +2785,7 @@ func TestCCIPRouter(t *testing.T) {
}
})

t.Run("hen sending a Valid CCIP Message but the user does not have enough funds of the fee token, it fails", func(t *testing.T) {
t.Run("When sending a Valid CCIP Message but the user does not have enough funds of the fee token, it fails", func(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a test for this specific case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about it initially, but that requires me to use another program as the caller (so that it's a PDA) and guarantee that the balance is just right. It seems like an overkill to create a new program (or extend the ccip-receiver) just to test this fairly basic check.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's avoid having more ccip receiver examples

@toblich toblich requested a review from agusaldasoro December 18, 2024 20:52
@toblich toblich merged commit e7d9aa1 into main Dec 19, 2024
17 checks passed
@toblich toblich deleted the fix/accidental-caller-pda-closing branch December 19, 2024 02:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants