Resumo

  • O RFC 3165 separou o script armazenado da linha de lançamento que escolhia o programa, os argumentos e os controles de execução.
  • No exemplo VACM de emergência, o grupo júnior só podia gravar os objetos de início e argumentos de uma linha preconfigurada; os seniores podiam instalar scripts e preparar os botões.

Publicado em agosto de 2001, o Script MIB propunha executar funções de gestão perto dos sistemas administrados. A interface permitia transferir e habilitar um script, iniciá-lo, observar uma execução, suspendê-la ou encerrá-la e recuperar seus resultados. Não impunha uma linguagem ou ambiente específico. Se a implementação permitisse, até código nativo compilado poderia ser executado. Portanto, a proposta não era apenas uma sintaxe de comando remoto: definia um ciclo de vida para tarefas de gestão delegadas.

A escolha decisiva foi separar o script do mecanismo que o inicia. Uma entrada de smScriptTable identifica o código e sua origem. Uma entrada de smLaunchTable — o “botão de lançamento” do RFC — associa um script a argumentos e controles, como o limite de execuções simultâneas. Um único SNMP SET pode acionar a entrada já preparada. Outra tabela expõe depois estado, resultados e controles da execução.

Essas entradas podem ter proprietários diferentes. smLaunchOwner identifica o proprietário administrativo da linha de lançamento; as execuções iniciadas por ela herdam esse proprietário. smLaunchScriptOwner e smLaunchScriptName identificam o script escolhido. Na MIB, “owner” é um índice administrativo e um ponto de aplicação de políticas, não prova que determinada pessoa ou conta do sistema autenticou a solicitação.

A seção 8.3 concretiza a divisão. O grupo VACM junior pode ler scripts, botões e resultados do proprietário emergency. Sua visão de escrita libera apenas smLaunchStart e smLaunchArgument para essas entradas. O grupo sênior pode instalar scripts de emergência e configurar os botões adequados. Assim, o operador júnior pode iniciar uma ação preparada sem receber os mesmos direitos MIB usados para criá-la ou reconfigurá-la.

Isso é um exemplo de configuração, não o relato de uma implantação real. O RFC 3165 tampouco padroniza um sandbox universal. Diz que o runtime pode usar o proprietário para aplicar perfis de segurança, mas deixa detalhes do runtime e da linguagem para cada implementação. Não especifica com qual identidade do sistema o script roda, quais arquivos e destinos de rede pode alcançar nem se os argumentos são seguros. Uma visão SNMP restrita limita os objetos que alguém consegue alterar; não torna inofensivo o programa selecionado.

Permitir o início não era a única superfície relevante. Quem podia gravar argumentos também podia influenciar o comportamento do script preparado. Autoria do código, proprietário da linha, permissão de invocar e privilégios do runtime eram controles ligados, mas distintos. O RFC 3165 substituiu o RFC 2592, de 1999, sem demonstrar adoção. Seu legado histórico mais preciso é mostrar como dividir criação, configuração, início e observação entre funções de gestão, em vez de concentrá-las em um único administrador todo-poderoso.

Fontes: RFC 3165, §§ 3–5, 8.1–8.3 e 10; RFC 2592; RFC 2575, controle de acesso baseado em visões; RFC 3415, especificação VACM posterior; RFC 3411, arquitetura SNMP.

Para conferir o histórico documental e os limites entre padrões — não como evidência de adoção — consulte o texto do RFC 3165 no Datatracker, seu registro, o Internet-Draft versão 04, o RFC 3414 sobre USM, o RFC 3416 sobre operações, o RFC 3417 sobre transportes, o RFC 3418 sobre MIB e o registro IANA de números SMI e linguagens.