Résumé

  • FTP conservait trois informations de contrôle d’accès : USER, PASS et ACCT. La réussite de l’étape du mot de passe ne prouvait donc ni la fin de la connexion logique ni l’autorisation de toute opération ultérieure.
  • 332 était une réponse intermédiaire positive. Après une commande de fichier, elle signifiait aussi que le serveur gardait la commande en suspens ; 532 indiquait au contraire qu’il l’avait rejetée et qu’il faudrait la renvoyer après ACCT.
  • Le protocole n’imposait aucune signification universelle au compte. Les RFC décrivent une place dans la machine d’états, pas une carte de paiement, un second mot de passe, un identifiant mondial ni une mesure du déploiement actuel.

Une réussite qui ouvrait une question

Une interface moderne présente volontiers l’authentification comme une fonction binaire : couple correct, session ouverte ; couple incorrect, refus. La séquence FTP était plus riche. Après USER, le serveur pouvait demander PASS. Après un mot de passe accepté, RFC 959 autorisait soit 230 User logged in, soit 332 Need account for login.

Le premier chiffre de 332 empêche de parler d’échec. Une réponse de classe 3 accepte la commande précédente mais retient l’action jusqu’à réception d’une information complémentaire. Le client devait fournir ACCT, non répéter le mot de passe.

Cette nuance change la preuve disponible. Le serveur pouvait avoir validé le secret associé à l’utilisateur tout en refusant de choisir à sa place le compte local auquel rattacher la consommation de ressources ou l’accès demandé. « Mot de passe correct » et « session prête » restaient deux propositions distinctes.

Le compte venait des systèmes que le réseau reliait

L’origine est concrète. En août 1972, RFC 385 ajouta ACCT au protocole décrit un mois plus tôt. Des systèmes tels que TENEX exigeaient, en plus de l’utilisateur et du mot de passe, une indication de compte séparée.

Le texte insistait sur la différence avec PASS. Le compte n’était pas nécessairement lié à USER, pouvait arriver à tout moment et pouvait même changer entre deux transferts du même utilisateur. Ce n’était donc pas simplement un troisième facteur d’identité placé au bout d’un formulaire.

Le mot « account » ne permet pas davantage de conclure à une facturation monétaire. FTP transportait une chaîne Telnet, tandis que le système distant en déterminait le sens. Projet, allocation de calcul, domaine d’autorisation ou centre de coût demeuraient des interprétations locales. Le protocole standardisait la demande, pas l’institution qui se cachait derrière elle.

Avant 332, le même état portait d’autres nombres

RFC 542 incorpora la commande en 1973. Il distinguait déjà le compte requis pour se connecter du compte exigé seulement pour un accès précis, par exemple le stockage. Mais son vocabulaire numérique différait : 331 Enter account signalait alors le complément de connexion, et 433 demandait un compte avant de renvoyer une commande de transfert.

RFC 640 réorganisa les réponses en 1974 afin qu’un automate puisse décider de l’état suivant à partir des chiffres, sans analyser le texte libre du serveur. La classe 3 devint l’intermédiaire positif ; la classe 5, l’achèvement négatif durable de la requête exacte. Le second chiffre 3 regroupait authentification et comptabilité.

Dans ce schéma, 331 prit le sens « nom accepté, mot de passe requis », 332 « compte requis pour la connexion », et 532 « compte requis pour stocker des fichiers ». Une capture ancienne ne peut donc être interprétée avec le dictionnaire de 1985. Les numéros ont changé pour mieux préserver la même différence d’autorité.

Le serveur pouvait garder ou abandonner l’intention

Le point le plus subtil apparaît après la connexion. Selon RFC 765, repris par RFC 959, un utilisateur déjà connecté pouvait lancer une commande telle que STOR, puis découvrir que ce stockage particulier exigeait un compte.

Si le serveur conservait la commande en attendant ACCT, il répondait 332. Le client n’avait qu’à fournir le renseignement manquant : l’intention initiale restait sous la garde du serveur. Si le serveur ne conservait pas la commande, il répondait 532. Après avoir fourni le compte, le client devait renvoyer STOR.

Deux messages qui semblent dire la même chose — « compte nécessaire » — décrivaient donc des obligations différentes. Après 332, répéter aveuglément l’opération risque de la dupliquer dans une mise en œuvre mal conçue. Après 532, ne pas la répéter garantit qu’elle ne commencera jamais. Le code de réponse faisait office de reçu pour la conservation de l’intention, non pour le résultat du transfert.

532 ne signifiait pas que le disque était plein

La proximité du stockage favorise une autre confusion. Le code 532 n’est pas une mesure de capacité. RFC 959 réserve 452 à l’insuffisance d’espace dans le système et 552 au dépassement d’une allocation pour le répertoire ou l’ensemble de données courant.

Un compte manquant, un système saturé et un quota dépassé sont trois causes différentes. La première réclame un contexte de contrôle ; la deuxième, de la capacité ; la troisième, une modification de l’allocation ou de la politique. Les réduire à « erreur d’envoi » détruit la prochaine action correcte.

Changer d’utilisateur ne réécrivait pas le transfert en cours

FTP autorisait un nouveau USER sur la même connexion de contrôle. RFC 959 précise que cette commande efface les informations d’utilisateur, de mot de passe et de compte, puis recommence la séquence de connexion. Les paramètres de transfert restent inchangés et un transfert déjà engagé se termine sous les anciens paramètres d’accès.

La transition n’est donc ni globale ni rétroactive. Une nouvelle identité ne prend pas possession des octets déjà en mouvement. Inversement, l’ancien compte ne doit pas être présumé valable pour les commandes suivantes. REIN efface lui aussi le contexte d’utilisateur et de compte sans fermer la connexion, tout en rétablissant les autres valeurs par défaut.

Une corrélation fondée seulement sur l’identifiant de connexion manque cette chronologie. Pour savoir quel contexte gouvernait une opération, il faut connaître le dernier USER, ACCT, REIN ou rétablissement de connexion antérieur à cette opération.

Comprendre ACCT n’obligeait pas à l’exiger

RFC 1123 plaça ACCT dans l’ensemble minimal que devaient prendre en charge clients et serveurs FTP, sous réserve de l’exception liée au système de fichiers ou au système d’exploitation. L’exigence empêchait un client simplifié d’être incapable de représenter une étape licite du protocole.

Elle n’imposait pas un compte à chaque site. Une commande comprise mais sans utilité locale pouvait recevoir la réponse positive 202 indiquant qu’elle était superflue. L’obligation de parler le vocabulaire n’était pas l’obligation d’appliquer partout la politique qu’il rendait possible.

Le registre IANA des commandes et extensions FTP classe encore ACCT parmi les commandes de base de contrôle d’accès et renvoie à RFC 959. Cette persistance établit la place normative ; elle ne compte pas les serveurs, ne révèle aucun paramètre et ne prouve aucune utilisation actuelle.

La machine d’états protégeait un désaccord légitime

FTP ne cherchait pas à unifier les modèles de compte de machines très différentes. Il donnait au serveur un moyen d’exiger son contexte local, et au client un moyen de savoir si son mot de passe avait échoué, si une donnée complémentaire manquait et si la commande précédente existait encore.

La leçon durable n’est pas de remettre ACCT dans toutes les interfaces. Elle consiste à ne pas condenser l’identité, le choix du contexte de ressources et l’acceptation d’une opération en un seul booléen. Quand un produit supprime un état du modèle visible, cet état ne disparaît pas : il revient sous forme de convention privée, de script fragile ou d’erreur impossible à diagnostiquer.

Sources et limites

Le dossier fermé comprend RFC 385, RFC 542, RFC 640, RFC 765, RFC 959, RFC 1123 et le registre IANA. Ces textes établissent les états et leur histoire, non le sens d’un compte donné, sa confidentialité, la fréquence d’emploi moderne ou le succès d’un fichier particulier.