Debian, la distribution Linux, se retrouve au cœur d'un débat complexe sur la gestion des noms d'utilisateur dans ses systèmes. L'incident, surnommé avec humour « la boîte de Pandore des noms d'utilisateur », met en lumière un problème fondamental des systèmes Unix/Linux : les limitations historiques et les conventions parfois arbitraires dans la gestion des noms d'utilisateur.Origine du problème
Le débat a été déclenché par une demande de modification concernant les règles qui régissent les noms d'utilisateur. Traditionnellement, Unix et ses dérivés imposent des restrictions strictes sur les noms d'utilisateur, comme l'interdiction de certains caractères (par exemple, des espaces ou des symboles spéciaux) et des limites sur la longueur des noms. Ces restrictions, bien que compréhensibles à l'époque des débuts d'Unix, semblent aujourd'hui dépassées, notamment dans des environnements modernes où les identifiants sont souvent synchronisés avec des systèmes externes comme Active Directory ou LDAP.
L'objectif initial de cette révision était de permettre une plus grande flexibilité pour répondre aux besoins des utilisateurs modernes. Cependant, cette ouverture a rapidement exposé des problèmes plus profonds liés à la compatibilité, la sécurité et les attentes des utilisateurs.
Les défis techniques et sociaux
L'assouplissement des règles pour les noms d'utilisateur soulève plusieurs problèmes :
- Compatibilité des outils : Beaucoup de scripts et d'applications sur Linux supposent des noms d'utilisateur simples et sans caractères spéciaux. Les modifications proposées risquent de casser ces outils.
- Sécurité : Autoriser des caractères non traditionnels, comme des espaces ou des caractères de contrôle, pourrait être exploité à des fins malveillantes. Par exemple, un utilisateur mal intentionné pourrait créer un compte dont le nom ressemble à une commande système pour tromper les administrateurs.
- Adoption communautaire : Debian est connue pour son approche rigoureuse et sa large base d'utilisateurs. Toute décision qui perturbe les flux de travail existants ou introduit des risques pourrait rencontrer une opposition farouche de la communauté.
- Normes historiques : Les limites actuelles ne sont pas seulement techniques ; elles sont également culturelles. Les administrateurs système sont habitués à des conventions spécifiques, et les changer nécessiterait un effort de communication important.
La situation de l'utilitaire useradd
On a longtemps dit que nommer les choses était l'une des choses les plus difficiles à faire en informatique. C'est peut-être vrai, mais ce n'est rien comparé au défi que représente la gestion correcte des noms d'utilisateur dans les applications. C'est particulièrement vrai lorsque plusieurs applications sont impliquées, et qu'elles sont toutes supposées se mettre d'accord sur les caractères autorisés ou non. Le projet Debian est actuellement confronté à ce problème, car deux utilitaires de création d'utilisateurs ne sont pas d'accord sur les noms autorisés. Un plan est en place pour régler ce problème avant la publication de Debian 13 (« trixie ») dans le courant de l'année prochaine.
L'utilitaire useradd fait partie du projet shadow-utils, qui comprend des programmes pour gérer les comptes d'utilisateurs et de groupes. La suite shadow-utils est incluse dans le paquet passwd de Debian. Pour des raisons historiques, et pour éviter toute confusion avec le projet amont, la version Debian des sources de shadow-utils est souvent appelée « src:shadow ».
La plupart des utilisateurs de Debian ne travaillent pas directement avec useradd ou groupadd. À la place, Debian fournit depuis longtemps ses propres utilitaires adduser (et addgroup), écrits à l'origine par le fondateur Ian Murdock. Ils agissent comme des interfaces plus simples avec useradd et utilisent les valeurs par défaut du système Debian pour créer les répertoires personnels et les configurations des utilisateurs. Il faut noter que useradd et autres sont devenus beaucoup plus complets depuis que les utilitaires de Debian ont été introduits, mais le projet continue néanmoins à les maintenir.
Petites tables de Bobby
En juin, Chris Hofstaedtler, développeur Debian et responsable de src:shadow, a signalé un bogue contre le paquet adduser. Le paquet src:shadow avait abandonné un correctif spécifique à Debian, introduit à l'origine en 2003 par Karl Ramm, pour autoriser des caractères bien au-delà de ce qui était autorisé par le projet shadow-utils en amont. Dans le correctif, Ramm a écrit :
« Je n'arrive pas à justifier pourquoi les caractères autres que ':' et '\0' devraient être interdits dans les noms de groupes et d'utilisateurs (à part '-' comme caractère de tête). Ainsi, les outils de maintenance n'ont plus lieu d'être ».
Hofstaedtler a dit qu'il avait compris certains des objectifs du correctif à partir d'anciens rapports de bogues qui avaient été « corrigés » par le correctif, et qui demandaient deux choses qui n'étaient pas autorisées par les shadow-utils en amont : des noms d'utilisateur avec des caractères majuscules ou qui sont purement numériques. Hofstaedtler a déclaré que les noms en majuscules avaient été autorisés dans le projet shadow-utils en amont « il y a longtemps« », mais qu'il semblait être une mauvaise idée d'autoriser les noms d'utilisateur purement numériques.
Le correctif permettait cependant bien plus que les noms en majuscules et les noms purement numériques. Avec le correctif déposé dans la version 1:4.15.2-2 du paquet source shadow, l'un des tests d'adduser - qui autorisait explicitement un nom d'utilisateur rappelant une célèbre bande dessinée de xkcd (""bob;>/hacked"") - avait échoué :
« Pour src:shadow, j'aimerais vraiment qu'il n'y ait pas de divergence en upstream à cet égard. Je pense que si nous avons des exigences claires, nous (je) pouvons les soumettre en amont et je m'attends à ce que l'amont accepte les correctifs. J'ai le sentiment qu'il serait très difficile de justifier l'utilisation de "bob;>/hacked" ».
Hofstaedtler a dit que le correctif avait été réappliqué pour le moment, il a été inclus à nouveau dans la version 1:4.15.2-3, mais il a demandé si les exigences en matière de nom d'utilisateur pouvaient être réglées à temps pour la publication de Debian « trixie ». Si le correctif était entièrement abandonné, alors useradd restreindrait les noms d'utilisateur au standard POSIX, à l'exception de l'autorisation du caractère « $ » à la fin d'un nom d'utilisateur
Marc Haber, développeur Debian et responsable d'adduser, a répondu fin octobre que d'autres tests échouaient également, et qu'il pensait que « useradd en amont est trop pointilleux ici ». Puisque adduser dépend de useradd, il ne peut pas créer d'utilisateurs que useradd rejetterait, il a dit qu'il aimerait se synchroniser sur ce qui serait autorisé ou non.
Dans le cadre de la recherche sur ce qui devrait être autorisé dans les noms d'utilisateur, Haber a repris la page wiki UserAccounts de Debian, qui décrit les outils et la politique de Debian en matière de noms d'utilisateur, et a commencé à examiner si le projet devrait assouplir ses exigences en matière de noms d'utilisateur.
Limites des noms d'utilisateur
L'une des questions qui se posent lorsque l'on examine les noms d'utilisateur n'est pas seulement celle des caractères autorisés, mais aussi celle de la longueur autorisée du nom d'utilisateur. La documentation de shadow-utils ne précise pas la longueur des noms d'utilisateur ni le codage utilisé.
Cependant, afin d'assurer la portabilité entre les systèmes, la norme POSIX stipule que les noms d'utilisateur ne doivent pas inclure de caractères non ASCII. La norme stipule que les noms d'utilisateur doivent être « composés de caractères du jeu de caractères des noms de fichiers portables ». Ce jeu comprend les chiffres de 0 à 9, les lettres majuscules et minuscules de « a » à « z », le point (.), le trait de soulignement (_) et le trait d'union (-). Elle précise également que les noms d'utilisateur ne doivent pas commencer par un trait d'union.
Il est toutefois possible d'attribuer des caractères en dehors de cet ensemble avec les outils disponibles. Mais les distributions Linux mettent généralement en place des garde-fous dans les configurations adduser et useradd pour empêcher les administrateurs de créer involontairement des noms d'utilisateur avec des caractères non ASCII. Ces configurations peuvent être remplacées par l'option --allow-bad-names de adduser ou l'option --badname de useradd.
En novembre, Haber a posté un message sur debian-devel disant qu'il avait « ouvert une boîte de Pandore particulièrement désagréable » et qu'il découvrait que les choses étaient plus compliquées qu'il ne l'avait compris. Il a demandé des commentaires et des opinions sur un certain nombre de questions concernant le fait de savoir si Debian devrait autoriser les caractères non-ASCII pour les noms d'utilisateur, comment le faire si c'est le cas, et s'il était plus approprié de documenter les conseils sur les noms d'utilisateur dans le manuel de politique de Debian plutôt que sur son wiki. Il a suggéré d'autoriser UTF-8 pour les comptes d'utilisateurs ordinaires, mais de restreindre à ASCII les comptes système créés par les paquets Debian.
Richard Lewis a demandé si l'autorisation de l'UTF-8 ouvrirait la porte à « certains des abus décrits » dans un article du LWN de 2021 à propos de failles dans la gestion de l'Unicode qui ont conduit à des exploits de sécurité. Il a déclaré qu'il semblait être une mauvaise idée de faire ce changement, même s'il serait plus agréable pour les utilisateurs d'avoir l'option.
Haber a déclaré qu'il n'était pas sûr qu'il soit dangereux d'autoriser les noms d'utilisateur UTF-8, « puisque nous pouvons nous attendre à ce que d'autres commandes gèrent gracieusement un flux d'octets, n'est-ce pas ? » De plus, les administrateurs locaux peuvent déjà assouplir les restrictions pour autoriser les noms d'utilisateur UTF-8, mais Debian ne teste pas ces cas d'utilisation. Debian deviendrait « plus robuste » si elle supposait que les caractères UTF-8 sont utilisés dans les noms d'utilisateur. « Les vulnérabilités qui pourraient être exploitées en ayant des noms d'utilisateurs non-ascii sont déjà présentes aujourd'hui, mais elles n'ont pas encore été découvertes ».
Timo Röhling a déclaré qu'il serait raisonnable d'atténuer les attaques possibles par homographe en interdisant les alphabets mixtes « »tels que les lettres cyrilliques et latines dans le même nom« ». Haber a dit que cela n'allait pas aider si un utilisateur pouvait écrire directement dans /etc/passwd, et qu'il n'était pas disposé à implémenter cela lui-même dans adduser. Il accepterait cependant le code et les cas de test écrits par d'autres.
Claviers
Outre les questions de sécurité, la prise en charge des noms d'utilisateur non ASCII pose d'autres problèmes pratiques. Étienne Mollier a fait remarquer qu'il avait « un caractère assez bizarre » dans son prénom qui posait un problème s'il devait se connecter en utilisant un clavier qui n'avait pas la capacité de transcrire les caractères « e » aigus minuscules ou majuscules (« é » ou « É »). C'est pour cette raison qu'il préfère conserver un nom d'utilisateur entièrement ASCII et qu'il « ne se sentirait pas visé si la prise en charge de l'unicode pour l'ouverture de session n'avait jamais lieu ». Mais il serait bon que le champ gecos du fichier passwd soit correctement pris en charge par l'Unicode afin d'afficher correctement les noms réels des utilisateurs.
Non seulement il est difficile de taper « é » sur certains claviers, mais ce mot peut aussi être codé de plusieurs façons. Gioele Barabucci a fait remarquer qu'il pouvait s'agir de « e avec accent », qui est codé en UTF comme U+00E9, ou de « e, combiné avec un accent [aigu] », ce qui correspondrait à U+0065 plus U+0301 :
« Si un système de saisie au clavier fournit la première séquence d'octets, mais que le nom d'utilisateur est stocké dans l'infrastructure de connexion en utilisant la seconde séquence d'[octets], une comparaison naïve ne trouvera pas l'utilisateur "émollier" dans le système. Unicode définit dans l'annexe 15 quelques formes de normalisation pour contourner ce problème. Mais l'utilisation correcte de ces formes de normalisation nécessite toujours une coordination et une normalisation entre tous les programmes accédant aux données ».
Il demande si POSIX ou d'autres normes fournissent une forme de normalisation pour les noms d'utilisateur encodés en UTF-8. Peter Pentchev a répondu que POSIX préconisait de s'en tenir au jeu de caractères des noms de fichiers portables pour garantir la portabilité. Haber a soutenu qu'il revenait aux administrateurs locaux de décider s'ils voulaient que leur base de données d'utilisateurs locale soit portable. « Je ne pense pas que nous devrions restreindre les administrateurs locaux qui n'ont pas besoin de ce type de portabilité.
Simon McVittie a recommandé que Debian envisage d'adopter la syntaxe du nom d'utilisateur de systemd et les concepts de « mode strict » et de « mode détendu ». L'outil systemd adhère à une convention de nommage stricte lors de la création de noms d'utilisateurs, mais il a une convention détendue pour accepter les noms d'utilisateurs créés par d'autres outils. McVittie a dit que cela semblait être un bon principe à suivre pour Debian, même si ses règles spécifiques peuvent différer de celles de systemd.
Haber a semblé être d'accord en partie, mais a dit que le mode strict de systemd était « encore plus strict que ce que nous autorisons actuellement pour les comptes système », et il n'a pas aimé que les règles de systemd (en particulier avec systemd-homed, que LWN a couvert récemment) ne soient pas configurables.
Une opportunité pour l'écosystème Linux
Bien que ce débat puisse sembler mineur, il illustre un problème plus large dans l'écosystème Linux : la tension entre l'héritage historique et les besoins modernes. D'autres distributions surveillent probablement la situation avec intérêt, car une solution efficace pourrait devenir un modèle à suivre. Debian a une occasion de montrer comment évoluer sans compromettre la stabilité. Cependant, comme toujours dans le logiciel libre, la décision finale sera probablement le fruit d'un consensus laborieux.
La « boîte de Pandore des noms d'utilisateur » de Debian est un rappel que même les détails apparemment insignifiants d'un système d'exploitation peuvent avoir des implications profondes. Qu'il s'agisse d'une opportunité d'innovation ou d'une source de frustration pour la communauté, la manière dont Debian résoudra ce problème pourrait définir une nouvelle norme pour les systèmes Unix/Linux.
Sources : Martin Fowler, Chris Hofstaedtler, Marc Haber (1, 2, 3), Debian Policy, Richard Lewis, Joe Brockmeier, Timo Röhling, Étienne Mollier, Gioele Barabucci
Et vous ?
Que pensez-vous de cette problématique ? Faut-il réformer les règles des noms d'utilisateur sous Debian ? Pourquoi ? Quels tests pourraient être mis en place pour évaluer l'impact des nouveaux noms d'utilisateur sur les outils existants ? Quelles garanties de compatibilité rétroactive pourraient être offertes si les règles sur les noms d'utilisateur évoluent ? Est-il envisageable de limiter les caractères autorisés en fonction du rôle des utilisateurs (par exemple, utilisateurs système versus utilisateurs normaux) ? Comment Debian peut-elle gérer les potentiels problèmes de sécurité liés à l’introduction de caractères spéciaux dans les noms d’utilisateur ? Serait-il utile de créer un outil ou une bibliothèque standardisée pour valider les noms d'utilisateur dans l'écosystème Linux ? Comment Debian pourrait-elle impliquer d'autres distributions Linux pour réfléchir à une norme commune ? Y a-t-il des cas d'utilisation concrets où l'élargissement des règles sur les noms d'utilisateur répondrait à des besoins pressants ? 
