During the drop off a database, xmysqladmin dropt the database and create a tar.gz inside /tmp without checking if the file exist already.
void dropdb_drop(FL_OBJECT *obj, long data)
if(!fl_show_question("WARNING!!!\nThis database will be delete.\nDo you want to continue?", 0))
if(!fl_show_question("WARNING!!!\nThis database will be delete.\nAre you sure?", 0))
cmd = (char *) malloc(2048);
sprintf(cmd, "%s %s/%s.tar%s %s%s/*", BACKUP, BACKUPDIR, g_dropdb_dbfname,
BACKUPSUFFIX, Setup.datapath, g_dropdb_dbfname);
if(g_mysql_connect(&connection, Setup.host, Setup.user, Setup.password))
fl_show_message("The database",g_dropdb_dbfname,"has been destroyed");
fl_show_alert("Cannot connect to server","","",0);
Possible to overwrite arbitrary files or get the content off the database.
Maybe more bugs into this soft ;)
Yes, perhaps BACKUPDIR could be set to "." in the Makefile?
Yes it's a solution. If the . directory is not world writable.
Upstream should find another solution.
I contact him, and propose him the . solution.
No upstream response.
*** Bug 95571 has been marked as a duplicate of this bug. ***
So we need to patch the Makefile (or remove the package) since upstream is silent.
mysql herd, do you feel like taking this one ?
rphillips: you're the only survivor in the old committers, let us know if you
accept to patch again.
I guess we'll have to mask/remove it if noone wants it.
Koon: can you hard mask it in my place please ?
Waiting approval from herd lead to remove it.
Package masked on vivo's request. Bug kept open until complete removal.
I don't agree that this is insecure temp file creation.
the permissions of the created file in /tmp are 644.
sure the design decision of creating /tmp/foo.tar.gz without checkign that it
already exists isn't great, but it's not bad given that xmysqladmin is run with
user permissions. it fails if the user doesn't have permissions to write there,
provided your /tmp is set up correctly with the sticky bit.
It looks like it should be acceptable to set umask(0077) before running tar.
Any news on this one?
MySQL herd doesn't really want to maintain this, since it's p.masked since a long time, I'd go for removal.
If none speaks up, I'll send the last rites email tomorrow, and remove from the tree two weeks after that.
Best regards, CHTEKK.
Removed from Portage.
Best regards, CHTEKK.