El 20/12/20 a les 12:27, Joan Montané ha escrit:
Missatge de Josep Lladonosa <[email protected]
<mailto:[email protected]>> 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>
[2] https://xkcd.com/327/
