[pacman-dev] [PATCH 1/2] alpm: check for invalid sync db before replacing original
Ivy Foster
ivy.foster at gmail.com
Thu Sep 8 18:50:08 UTC 2016
On 08 Sep 2016, at 12:55 pm -0400, Andrew Gregory wrote:
> On 09/07/16 at 10:28pm, Ivy Foster wrote:
> > On 07 Sep 2016, at 10:05 pm -0400, Andrew Gregory wrote:
> > > This runs the risk of conflicting with another db if dbext is "" or
> > > ".bak", for example, if I have repos core and core.bak, syncing core
> > > would clobber the core.bak db.
> >
> > Fair enough. I'll keep that in mind when addressing the note below.
> >
> > > > + if (rename(newdb, olddb) == -1) {
> > > > + ret = -1;
> > > > + handle->pm_errno = ALPM_ERR_DB_BACKUP;
> > > > + goto cleanup;
> > > > + }
> > >
> > > This is backwards. Instead of moving the good db out of the way and
> > > hoping we can move it back if something goes wrong, we should download
> > > the new database to a temp file then move it into place if it's good.
> >
> > Okay. I'll change that around tomorrow. Given the note before this
> > one, perhaps the thing to do is to download the new db to a tmpfile
> > named by mkstemp.
>
> As long as we're downloading directly into the db directory, ensuring
> we don't conflict with another db is impossible because, now that the
> extension is configurable, there are no limits on db file names. Even
> a tmpfile could conflict if the conflicting db file hasn't been
> downloaded yet. I see two ways around this: place restrictions on db
> names/extensions or download into a separate directory and
> move/symlink them over once validated.
>
> Using a separate directory with symlinks is probably a bit more fault
> tolerant because both the old and new versions of the db and its sig
> could coexist the entire time, but I doubt the small gain is worth the
> complexity.
> I am inclined to say that we should just reject database names
> beginning with '_' and use that as a prefix for any temporary files.
> That should be sufficient to prevent any conflicts and is trivial to
> check in register_syncdb.
I mean, the names returned by mkstemp are probably sufficient
protection. You provide a prefix and it provides six random characters
to follow. Personally, I'm willing to bet that nobody's using the
dbext ".db.tmp.XXXXXX", where each X is a random character...unless
they're deliberately *trying* to collide.
Either way, I'll have a look at it later this afternoon.
iff
More information about the pacman-dev
mailing list