- Status Nouveau
- Percent Complete
- Task Type Anomalie
- Category Services locaux → SMB
- Assigned To No-one
- Operating System Tous
- Severity Low
- Priority Very Low
- Reported Version 4.7.7
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by nxo - 09/07/2023
Last edited by nxo - 17/07/2023
FS#38504 - Problème via le partage SMB lorsque certains caractères spéciaux se trouve dans un nom de fichier
Bonjour,
Lorsqu’on essaye de créer/modifier/supprimer un fichier contenant certains caractères spéciaux sur un disque de la Freebox via un partage SMB depuis Linux ou Windows il se produit une erreur du type “le fichier n’existe pas”.
Le problème ne se produit pas lorsqu’on essaye les mêmes manipulations depuis l’explorateur de fichiers de l’interface d’administration de la Freebox (mafreebox.freebox.fr/#Fbx.os.app.explorer.app).
Seulement lorsqu’on essaye d’utiliser ce genre de noms de fichiers via un partage SMB.
Les caractères en question sont par exemple certains émoji (ex. émoji “fire” (\xF0\x9F\x94\xA5)), mais pas de problème avec d’autres (ex. ❤️). Peut-être un problème de version Unicode/UTF-8?
Peut-être un problème de configuration du charset dans le smb.conf?
En essayant d’ouvrir cette tâche je me suis rendu compte que ces mêmes caractères provoquent une erreur ici aussi. Je l’ai donc remplacé par son nom et valeur UTF-8.
Je vous joins l’erreur ci-après en remplaçant mon message original (colonne “detailed_desc”) par “…” dans le message d’erreur:
Query {INSERT INTO `flyspray_tasks` (project_id, date_opened, last_edited_time, opened_by, percent_complete, mark_private, supertask_id, closedby_version, closure_comment, task_priority, due_date, anon_email, item_status, task_type, product_category, product_version, operating_system, task_severity, item_summary, detailed_desc, user_ip) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)} with params {9,1688912958,1688912958,33923,0,0,0,0,,2,0,,1,1,100,318,5,2,Problème via le partage SMB lorsque certains caractères spéciaux se trouve dans un nom de fichier,”…“,82.65.143.28} failed! (Incorrect string value: ‘\xF0\x9F\x94\xA5),…’ for column `publicbugs`.`flyspray_tasks`.`detailed_desc` at row 1)
Le caractère que j’essayais d’ajouter à mon message comme exemple à vous montrer est l’émoji “fire” (https://apps.timwhitlock.info/unicode/inspect/hex/1F525) avec comme valeur en bytes UTF-8 “\xF0\x9F\x94\xA5” comme décrit dans l’erreur ci-dessus.
Merci
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
@nxo: Il faudrait faire un ticket ici : https://github.com/cifsd-team/ksmbd/issues Pourriez-vous faire ceci ?
En mettant en copie dans le ticket :
@mmakassikis
Merci d’avance.
Bonjour
Regardez les sources de samba, il y a des limitations de cractères dans les noms de fichiers comme par exemple:
‘>’ ou encore ‘<’ , etc…
Si vos emoj comportent une strings hexa contenant l hexa de ‘<’ ou ‘>’ … ça ne fonctionnera jamais.
Je vous invite a chercher sur ce forum les posts relatifs a des vulnérabilités XSS de freeboxOS dans les versions freeboxOS inférieure à 4.7.7
On y discute entre autre des problèmes d encodages de caractères spéciaux dans les noms de fichiers avec samba et dans le kernel (dans namei.c)
Depuis le blocage de la vulnérabilité XSS en 4.7.7, il peut y avoir des limitations supplémentaires dans freebox OS
Cordialement
nbanba
Bonjour
Plus de détails ici : https://dev.freebox.fr/bugs/task/37727
Cordialement
nbanba
Bonjour,
Je ne comprends pas bien votre commentaire @nbanba.
Je ne rencontre pas de problème lorsque j’essaye de créer un fichier contenant le caractère ‘<’ ou ‘>’ que ce soit depuis linux ou depuis l’interface de FreeboxOS. C’est un caractère interdit sur Windows ce n’est donc pas faisable depuis ce dernier.
Aussi, vous dites que “Si vos emojis comportent une string hexa contenant l’hexa de ‘<’ ou ‘>’ … ça ne fonctionnera jamais.”, mais dans l’exemple même que je vous ai donné dans mon post, aucun des hexa de ‘<’ (3C) ou de ‘>’ (3E) n’est contenu dans l’émoji que je vous ai cité: émoji “fire”/”feu” = “\xF0\x9F\x94\xA5”.
Dont la correspondance ASCII pour chaque hexa équivaut à: F0 = ‘ð’, 9F = ‘Ÿ’, 94 = ‘”’, A5 = ‘¥’.
Donc en prenant en compte cela, et en revenant aussi sur le fait que je n’ai pas de soucis à créer de fichier ou dossier contenant les caractères ‘<’ ou ‘>’ que ce soit depuis une VM linux sur la Freebox connectée en SMB ou depuis l’explorateur de fichier de FreeboxOS, j’ai du mal à comprendre ce que vous avez décrit, et de quelle manière cela s’appliquerait à ce sujet.
Merci pour votre aide.
Après avoir fait un peu plus de tests et recherches, il semblerait que les caractères qui provoquent le bug mentionné, que ce soit sur le partage SMB ou ici lorsque inclut dans un message, sont ceux qui sont encodés sur au moins 4 bytes en UTF‑8.
Tous les caractères Unicode (émojis inclus donc) que j’ai pu essayer qui sont encodés sur 3 bytes ou moins en UTF-8 (semble être 2 bytes en UTF-16), donc de versions Unicode moins récentes je suppose, ne provoquent pas de problème, sur le nommage de fichier en partage SMB ou ici lorsque inclut dans le message d’une tâche ou d’un commentaire.
Je vous lie une table Unicode d’émojis (non complète et à jour mais suffit pour ce test) dont je me suis servi pour ces tests: https://apps.timwhitlock.info/emoji/tables/unicode
Ainsi que l’inspecteur Unicode du même site pour individuellement avoir l’hexa Unicode et le nombre de bytes UTF-8 ou UTF-16 d’un caractère: https://apps.timwhitlock.info/unicode/inspect
Ce que j’ai trouvé dessus concernerait les “plans de code” d’Unicode dont le premier (plan 0 ou “BMP”) serait encodé sur 1 à 3 bytes, puis les plans 1 à 16 encodés sur 4 bytes.
https://www.wikiwand.com/en/Unicode#Code_planes_and_blocks
Donc encore une fois je suppose un problème de version Unicode sur les 2 plateformes concernés (ici et SMB de la Freebox) ou quelque chose dans le genre.
Pour SMB après un petit peu de recherche il semblerait qu’il soit peut-être possible de configurer cela via quelque chose comme le charset? pas sûr, dans le smb.conf, mais je ne sais pas du tout comment est installé et configuré SMB ici dans ce cas précis donc peut-être que ça ne s’applique pas du tout.
@Neustradamus_ je n’ai pas encore fait ce que vous m’avez demandé, est-ce que j’y procède quand même en précisant les éléments que je viens d’ajouter?
Merci
@nxo: Pour flyspray, est-ce possible de faire un ticket ici :
- https://github.com/flyspray/flyspray
Vous pouvez aussi l’installer en local pour faire des tests (version master) ^^
Pour le Server, est-ce que le problème apparaît aussi en activant la case SMBv1 qui permet d’utiliser Samba 3.0.37 GPLv2 de 2009 (un très vieux code) à la place de ksbmd/ksbmd-tools.
Si non, vous pouvez faire un ticket ici :
- https://github.com/cifsd-team/ksmbd/issues
@nxo: Avez-vous fait le nécessaire pour ksmbd ?
- https://github.com/cifsd-team/ksmbd/issues
Déjà 23 jours depuis mon précédent commentaire…
Vous m’en excuserez, étant débordé j’ai repoussé indéfiniment.
Pour essayer de passer SMB en v1 je n’ai trouvé que la case “Activer SMB2/SMB3” dans Paramètres de la Freebox → Partages de fichiers → Partages Windows, qui est cochée et que j’ai donc décoché, mais une fois cela fait je n’arrivais plus à accéder au partage, que ce soit via Windows (en ayant bien pris le soin d’activer SMB1 dans les fonctionnalités Windows) ou via ma VM Debian qui tourne sur la Freebox (le mount dans le cloud-init fail), et ayant essayé de redémarrer machine/vm/freebox.
Je viens de créer le ticket sur le github de ksmbd comme demandé : https://github.com/cifsd-team/ksmbd/issues/598
Concernant flyspray, je vous ai notifié au passage ayant rencontré une erreur en essayant de poster ce ticket, mais je n’ai pas vraiment de temps ou d’intérêt pour m’en occuper plus que ça, désolé et merci de votre compréhension.
@nxo: Oui pour activer Samba 3.0.37, il faut désactiver la case “SMBv2/SMBv3”.
SMBv1 = Samba 3.0.37
SMBv2/SMBv3 = ksmbd
Merci beaucoup pour le ticket ksmbd :)
J’espère que développeur principal va regarder rapidement !
Avez-vous ce bug aussi : https://dev.freebox.fr/bugs/task/34655 ?
Il n’y a pas de ticket pour ksmbd… uniquement pour OpenWrt donc le développeur principal ne s’en occupe pas malheureusement… - https://github.com/openwrt/packages/issues/12933
Pour Flyspray, c’est important de signaler les problèmes, faites un ticket ici svp :
- https://github.com/flyspray/flyspray/issues
Comme mentionné dans mon commentaire précédent, je n’ai pas réussi à accéder à mon disque dur en SMBv1.
Non je n’ai jamais rencontré le bug que vous avez mentionné.
https://github.com/flyspray/flyspray/issues/828
@mmakassikis: Avez-vous lu ce ticket ?
namjaejeon vous a parlé et attend votre retour sur le ticket ici : https://github.com/cifsd-team/ksmbd/issues/598