Résumé

  • RFC 3165 séparait le script stocké de l’entrée de lancement qui sélectionnait le script, ses arguments et ses paramètres d’exécution.
  • Dans son exemple VACM d’urgence, le groupe junior ne pouvait écrire que les objets de démarrage et d’argument d’une entrée préparée ; les seniors conservaient le droit d’installer le script et de configurer le bouton.

Publié en août 2001, le Script MIB proposait de rapprocher les fonctions d’administration des équipements qu’elles devaient gérer. L’interface permettait de transférer un script, de l’activer, de le lancer, d’en suivre une exécution, de la suspendre ou de l’arrêter, puis d’en récupérer le résultat. Elle n’imposait ni langage ni moteur d’exécution précis ; une implémentation capable de le faire pouvait même exécuter du code natif compilé. Il s’agissait donc d’un cycle de vie pour le travail délégué, et pas seulement d’une commande distante.

Le choix décisif consistait à distinguer le script du moyen de le lancer. Une ligne de smScriptTable identifiait le code et sa source. Une ligne de smLaunchTable, le « bouton de lancement » du RFC, associait un script à des arguments et à des paramètres, dont le nombre maximal d’exécutions simultanées. Une opération SNMP SET pouvait invoquer cette entrée préparée. Une table distincte exposait ensuite l’état, les résultats et les commandes de l’exécution.

Les deux lignes n’avaient pas nécessairement le même propriétaire. smLaunchOwner désignait le propriétaire administratif de la ligne de lancement ; les exécutions démarrées par celle-ci héritaient de ce propriétaire. smLaunchScriptOwner et smLaunchScriptName identifiaient le script sélectionné. Ce champ « owner » est un index de gestion et un point d’accroche pour les règles, pas la preuve qu’une personne ou un compte système donné a authentifié la requête.

La section 8.3 rend la séparation concrète. Le groupe VACM junior peut lire les scripts, boutons et résultats du propriétaire emergency. Sa vue d’écriture ne couvre que smLaunchStart et smLaunchArgument pour ces entrées. Le groupe senior peut, lui, installer les scripts d’urgence et préparer les boutons correspondants. L’opérateur junior peut déclencher une action déjà définie sans recevoir les mêmes droits MIB que son auteur.

Il s’agit d’un exemple de configuration, non du récit d’un déploiement réel. RFC 3165 ne définit pas non plus un bac à sable universel. Le texte indique qu’un moteur peut utiliser le propriétaire pour appliquer un profil de sécurité, mais laisse le comportement du moteur et du langage aux implémentations. Il ne dit pas sous quel UID système tourne le script, quels fichiers ou systèmes il peut atteindre, ni si les arguments sont sûrs. Une vue SNMP étroite limite les objets modifiables ; elle ne rend pas inoffensif le programme choisi.

La permission de démarrer n’était pas la seule surface importante. Un opérateur autorisé à écrire les arguments pouvait influer sur le comportement du script préparé. Auteur du code, propriétaire de la ligne, droit d’invocation et privilèges du moteur étaient des contrôles liés, mais non équivalents. RFC 3165 a remplacé le Script MIB de 1999, RFC 2592, en poursuivant la même ambition de gestion distribuée. Leur apport historique est plus précis qu’une promesse d’automatisation : ils montrent comment séparer création, configuration, lancement et observation.

Sources : RFC 3165, §§ 3–5, 8.1–8.3 et 10 ; RFC 2592 ; RFC 2575, contrôle d’accès par vues ; RFC 3415, spécification VACM ultérieure ; RFC 3411, architecture SNMP.

Pour l’historique documentaire et les limites des standards — et non comme preuve d’adoption — voir le texte Datatracker de RFC 3165, sa notice RFC, le projet Internet version 04, RFC 3414 sur USM, RFC 3416 sur les opérations, RFC 3417 sur les transports, RFC 3418 sur la MIB et le registre IANA des nombres SMI et des langages.