Newlines dans les noms de fichiers

24

Je comprends et accepte la prémisse que les scripts shell 1 défensifs sont à la fois prudents et, à plus long terme, plus durables.

Bon nombre des réponses aux questions de traitement de texte ici suivent ce principe en intégrant les contingences de réponses pour les noms de fichiers peu orthodoxes; pouvant contenir des espaces, des tirets et de nouvelles lignes.

Quelle est la prévalence des nouvelles lignes dans les noms de fichiers? Plus précisément:

  • Certaines applications créent-elles des noms de fichiers qui incluent des sauts de ligne par défaut?
  • Y a-t-il des situations où il serait souhaitable de créer de tels noms de fichiers?
  • Ou s'agit-il principalement d'une instance d'erreur de l'utilisateur?

[1] C'est-à-dire planifier et gérer le plus large éventail possible de scénarios et de contingences ...

Question inspirée du commentaire (plutôt plaintif) sur cette question .

jasonwryan
la source
4
La réponse courte est que les noms de fichiers bizarres avec des retours à la ligne et / ou des caractères non imprimables ne sont jamais une bonne pratique, les applications sensées ne les créent pas et vous ne les voyez vraiment que si quelqu'un essaie de casser vos scripts shell ou programmes qui ne gèrent pas correctement ces noms. Je laisserai d'autres personnes fournir des réponses plus détaillées avec des références et autres.
jw013

Réponses:

26

Je n'ai jamais vu un nom de fichier avec une nouvelle ligne autre que ceux délibérément créés pour tester les applications qui manipulent les noms de fichiers. Les noms de fichiers contenant des sauts de ligne peuvent apparaître car:

  • Un bug ou une erreur utilisateur (par exemple, un mauvais copier-coller) a entraîné un nom de fichier involontaire.
  • Certaines altérations du système de fichiers ont affecté un nom de fichier.
  • Quelqu'un a délibérément créé un nom de fichier «étrange» pour exploiter une faille de sécurité, où une application a fait plus confiance aux noms de fichiers qui lui ont été transmis qu'elle n'aurait dû.

POSIX définit un nom de fichier comme «un nom composé de 1 à {NAME_MAX} octets utilisé pour nommer un fichier. Les caractères composant le nom peuvent être sélectionnés dans l'ensemble de toutes les valeurs de caractères à l'exclusion du caractère barre oblique et de l'octet nul. Les noms de fichiers dot et dot-dot ont une signification particulière. »Il n'y a aucune garantie que chaque système de fichiers acceptera des noms de fichiers« étranges »(les seuls caractères garantis sont les lettres ASCII, les chiffres, le point, le trait d'union et le trait de soulignement , c'est A-Z-à- dire a-z, 0-9et ._-, avec trait d'union interdit en première position), mais la plupart des systèmes de fichiers natifs sur les unités modernes le font.

Gilles 'SO- arrête d'être méchant'
la source
Donc, spacesdans les noms de fichiers ne sont pas garantis portables? Il serait utile de préciser que ces trois derniers caractères le sont period, underscore, and hyphen. Avec le lien souligné, c'est difficile à dire.
toxalot
4
@toxalot Non, les espaces ne sont pas garantis portables, ni ,(utilisés par RCS), :(utilisés par X.org), ~(utilisés par de nombreux programmes sur des fichiers de sauvegarde),… Mais ils sont pris en charge par presque tous les systèmes modernes.
Gilles 'SO- arrête d'être méchant'
22

Lors de la rédaction d'un article, je recueille souvent une bibliographie de fichiers PDF provenant de diverses sources. Tous ne contiennent pas les métadonnées correctes, ce qui signifie que je copie / colle parfois le titre du document du visualiseur PDF dans le nom de fichier. Cela entraîne souvent des sauts de ligne dans le nom du fichier, mais n'a jamais posé de problème avec les outils que j'ai utilisés.

À mon humble avis, il n'y a rien de «défensif» dans le codage d'une norme .. une norme qui stipule que les retours à la ligne sont autorisés dans les noms de fichiers. Si votre script ne gère pas tous les noms de fichiers autorisés dans la norme, alors votre script est cassé.

sml
la source
2
Merci pour l'exemple du monde réel; cela souligne votre point de vue sur la norme de façon assez éloquente ...
jasonwryan
6
+1 pour "Si votre script ne gère pas tous les noms de fichiers autorisés dans la norme, alors votre script est cassé " (non souligné dans l'original)
jw013
3
Voici l' argument d' un homme pour expliquer pourquoi nous devrions changer les caractères acceptés dans les noms de fichiers et je suis personnellement d'accord avec lui.
Chris Magnuson
⁺¹, je suis tombé sur ce post pour exactement la même raison! J'essaie juste de comprendre comment écrire une commande pour convertir les retours à la ligne en espaces.
Hi-Angel
2

Je n'ai jamais vu d'utilisateurs NORMAL utiliser des sauts de ligne dans les noms de fichiers. Il semble que leur objectif principal soit de (1) faciliter la piratage de votre système par les attaquants et (2) rendre plus difficile l'écriture de programmes sécurisés :-(. Cependant, les likes Unix modernes (tels que Linux) leur permettent , vous devez donc vous y préparer si vous voulez un programme qui résiste aux attaques.

«Noms de fichiers et chemins d'accès dans Shell: comment le faire correctement» montre comment gérer cela correctement.

user45404
la source
Je suis un utilisateur normal et j'ai des retours à la ligne dans mes noms de fichiers. Le scénario énoncé dans la réponse de @sml m'est arrivé plus d'une fois. Ce qui m'intéresse, c'est comment utiliser une nouvelle ligne dans un nom de fichier pour "renverser le système"? Avez-vous des sources expliquant cela?
Joseph R.
@JosephR. Je ne peux pas penser à un moyen de compromettre un système, mais vous pouvez l'utiliser comme DOS pour des applications qui ne gèrent pas les nouvelles lignes (et
plantent à la