Missatge de Josep Lladonosa <jlladono@gmail.com> del dia dg., 20 de des. 2020 a les 11:56:
Hola,
Sembla que ja està encaminada la solució però volia aportar la meva opinió:
Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de fitxer pot contenir-ne, d'espais.
Potser es pot reportar un bug al creador del script i fins i tot fer una proposta per resoldre'l, "escapant" el nom de fitxer.
Efectivament, en el cas particular que ens ocupa hi ha dues coses que coincideixen, i fan aparèixer el problema:
1. En algunes llengües, la variable que conté el nom del mes conté un espai. És el cas de català si s'usa el format %B per a tots els mesos menys abril, agost i octubre.
2. L'script no escapa els possibles espais de les variables i si hi ha espais, aleshores l'script no fa el que se suposa que ha de fer.
L'error és a 2 (no es pot assumir alegrement que una variable no té espais). El problema es podria rodejar usant "%OB" a l'script per a extraure els noms de mesos (totes les llengües que he mirat retornen els mesos sense espai), però això segueix sense garantir que les cadenes no tindran espais, i el problema descrit a 2 podria tornar a reproduir-se. La solució bona és escapar els espais de les variables, amb les cometes dobles.
Com diu el Josep, el millor és obrir un bug a automysqlbackup i, idealment, aportar-hi la solució.
Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] i l'he encertat de ple: com es pot veure a la funció shell, definida a partir de la línia 424, tant $1 com $2 no estan degudament protegits.
El fet que un espai en blanc trenqui la creació de còpies de seguretat, per si sol, entenc que mereix que el bug tingui una severitat major que normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre correspongui a una dada facilitada per l'usuari, el nom de la base de dades, em fa témer que podria arribar a explotar-se com a vulnerabilitat per a la injecció de comandes. Per exemple: una configuració que fes còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb Postgres, on tinc experiència) podria, segons els permisos, destruir la base de dades, el que ho faria un bug crític [2]. Ara bé, no he comprovat fins a quin punt és explotable, però és quelcom que fa saltar totes les meves alarmes.
També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es tractés d'una "cometa simple", causaria error i no completaria el backup.
L'altre tema és el d'anomenar els backups en funció del locale, que està bé per a humans però és terrible per a gestió automàtica per a màquines. Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de fer servir immediatament) obriria dos bug reports: el primer, més greu, amb el problema d'escapament dels paràmetres de la funció dbdump; i el segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de forma humana (com fins ara) o mecànica (en un format YYYY-MM-DD o similar però respectant l'ordre any-mes-dia i 4-2-2 dígits).
No em sento còmode obrint-los jo per tractar-se d'una eina que no
uso, doncs no podria donar respostes a preguntes addicionals del
desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri.
[1] <https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup> cf. <https://tracker.debian.org/pkg/automysqlbackup>