"Doble quote lost in space", m'encanten aquestes novel•les de misteri col•laboratives. +1000
Le 20 décembre 2020 13:36:42 GMT+01:00, Eloi <entfe...@gmail.com> a écrit : >El 20/12/20 a les 12:27, Joan Montané ha escrit: >> >> >> Missatge de Josep Lladonosa <jllad...@gmail.com >> <mailto:jllad...@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> > >[2] https://xkcd.com/327/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
