Propiedad y Permisos de Cuentas

La regla del propietario escribe es el invariante de seguridad central de Solana: solo el programa propietario de una cuenta puede modificar sus data (y ciertos metadatos). Los firmantes autorizan las transferencias de lamports; los propietarios autorizan las mutaciones de datos.

Receta

#[derive(Accounts)]
pub struct SecureUpdate<'info> {
    #[account(
        mut,
        has_one = authority @ MyError::Unauthorized,
        constraint = data.is_active @ MyError::Inactive,
    )]
    pub data: Account<'info, MyData>,
    pub authority: Signer<'info>,
}

Cuándo usar esto:

• Cada instrucción que muta cuentas propiedad del programa
• Auditoría de programas para verificar la falta de comprobaciones de firmante o propietario
• Diseño de flujos CPI donde el llamado debe confiar en las cuentas pasadas
• Comprender por qué UncheckedAccount es peligroso por defecto

Ejemplo de Trabajo

use anchor_lang::prelude::*;
 
#[account]
pub struct MyData {
    pub authority: Pubkey,
    pub is_active: bool,
    pub balance: u64,
}
 
#[program]
pub mod permissions {
    use super::*;
 
    pub fn update_balance(ctx: Context<UpdateBalance>, new_balance: u64) -> Result<()> {
        ctx.accounts.data.balance = new_balance;
        Ok(())
    }
 
    pub fn steal_attempt(ctx: Context<StealAttempt>) -> Result<()> {
        // Esto FALLA en tiempo de ejecución - el llamador no es el propietario de la cuenta víctima
        Ok(())
    }
}
 
#[derive(Accounts)]
pub struct UpdateBalance<'info> {
    #[account(mut, has_one = authority)]
    pub data: Account<'info, MyData>,
    pub authority: Signer<'info>,
}
 
#[derive(Accounts)]
pub struct StealAttempt<'info> {
    #[account(mut)]
    pub data: Account<'info, MyData>, // Anchor verifica propietario == programa
    pub attacker: Signer<'info>,
}

Lo que esto demuestra:

• Account<'info, MyData> verifica que el propietario == este programa
• has_one = authority vincula los derechos de mutación a una pubkey almacenada
• El atacante no puede pasar la cuenta de otro usuario a menos que sea la autoridad

Análisis Profundo

Capas de Permisos

Permisos CPI

• El llamador pasa cuentas al llamado; el llamado revalida
• El programa propietario puede usar CPI para delegar transferencias de tokens (SPL)
• invoke_signed permite a los programas firmar para PDAs

Trampas Comunes

• UncheckedAccount sin restricciones - sustitución arbitraria de cuentas. Solución: añadir comprobaciones de propietario, semillas o has_one.
• Signer != authority - el usuario firma pero no es la autoridad almacenada. Solución: has_one = authority en Signer.
• Banderas escribibles en cuentas no autorizadas - el tiempo de ejecución puede rechazar o el programa propietario debe permitir. Solución: marcar solo las cuentas escribibles que su programa posee y tiene la intención de mutar.
• Falta de mut en cuentas que cambian - operación silenciosa sin efecto o error de compilación. Solución: #[account(mut)] en cada cuenta modificada.
• Confundir el propietario del token con la autoridad de la cuenta - SPL tiene propietario y delegado separados. Solución: usar restricciones SPL o CPI correctamente.

Alternativas

Preguntas Frecuentes

Relacionado

• Cuentas del Sistema vs. Cuentas de Programa - quién posee qué
• Estado Propiedad del Programa - diseño de cuentas de estado
• Conceptos Básicos del Modelo de Cuentas - ejemplos de restricciones

Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.