[pacman-dev] [PATCH 1/2] alpm: check for invalid sync db before replacing original

[Andrew Gregory]

On 09/07/16 at 10:28pm, Ivy Foster wrote:
> On 07 Sep 2016, at 10:05 pm -0400, Andrew Gregory wrote:
> > On 09/07/16 at 07:22pm, ivy.foster at gmail.com wrote:
> > > From: Ivy Foster <ivy.foster at gmail.com>
> 
> > This is a step in the right direction, but the problem of downloading
> > an invalid db over a valid one still exists.  The errors given in the
> > bug report are not actually from the invalid db, they're from invalid
> > signature files.  If we download a junk db but no signature file, the
> > valid db would still be overwritten by the invalid one.
> 
> Ah, my mistake. I should've actually looked at sync_db_validate; I
> just assumed that it handled validation in general, not just
> signatures. Also, unfortunately, I forgot about .files dbs.
> 
> > >  	/* Sanity checks */
> > >  	ASSERT(db != NULL, return -1);
> > > @@ -218,10 +221,23 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db)
> > >  
> > >  	dbext = db->handle->dbext;
> > >  
> > > +	len = strlen(syncpath) + strlen(db->treename) + strlen(dbext) + 2;
> > > +	/* TODO fix leak syncpath and umask unset */
> > > +	MALLOC(newdb, len, RET_ERR(handle, ALPM_ERR_MEMORY, -1));
> > > +	snprintf(newdb, len, "%s/%s%s", syncpath, db->treename, dbext);
> > > +	len += 4;
> > > +	/* TODO fix leak syncpath and umask unset */
> > > +	MALLOC(olddb, len, RET_ERR(handle, ALPM_ERR_MEMORY, -1));
> > > +	snprintf(olddb, len, "%s.bak", newdb);
> > 
> > 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.