[Netarchivesuite-users] MySQL database , security and programmatic migration on startup - WHY?

Søren Vejrup Carlsen svc at kb.dk
Wed Apr 15 15:02:42 CEST 2009

Hi Nicolas.

Database-updates are handled by code from now to simplify matters.

However, you can make the changes from outside the code, if Necessary.

In 3.6.x, the only changes were an upgrade of the jobs table to version 4, which for MySQL can be done by the following statements

(which your IT-administrators then can execute on your behalf):


ALTER TABLE jobs CHANGE COLUMN forcemaxbytes forcemaxbytes bigint not null default -1;

ALTER TABLE jobs CHANGE COLUMN num_configs num_configs int not null default 0;

UPDATE TABLE  schemaversions SET version=4 WHERE tablename='jobs'; 





Fra: netarchivesuite-users-bounces at lists.gforge.statsbiblioteket.dk [mailto:netarchivesuite-users-bounces at lists.gforge.statsbiblioteket.dk] På vegne af nicolas.giraud at bnf.fr
Sendt: 14. april 2009 14:36
Til: netarchivesuite-users at lists.gforge.statsbiblioteket.dk
Emne: [Netarchivesuite-users] MySQL database ,security and programmatic migration on startup - WHY?



I am installing the NetArchive Suite  and setting my configuration. I am using MySQL for the database, and I have configured very strict access permissions, as my IT requires :

- root has full privileges and can only access from localhost
- the applications use a specific user with limited privileges (SELECT, INSERT, UPDATE, DELETE). That user is configured in settings.xml (parameter to the JDBC URL).

I have found something in NetArchiveSuite code that kind of bothers me. When initializing the GUIApplication class, the initialization of the site section triggers a check in MySQLSpecifics of some kind of  per-table version in the DB schema, and if needed, performs a programmatic migration (DBSpecifics line 212). This migration involves performing ALTER updates on the  database, which I don't intend, for security reasons, to allow to the application. So right now I'm getting an SQL exception because my configured user is limited to SELECT, INSERT, UPDATE, and DELETE. How comes such structural updates are done in Java? This seems to me a design fault, all schema modifications should be performed by SQL scripts executed as root on the local machine that hosts the database (or a separate Java program) , and not by the application itself. Also I believe that the version number should be at the schema scope, the table scope seems too thin to me, there is risk to leave the DB schema in an incoherent state.

So right now I have no other choice than compromising my security to cope with this. Sure it's not that big a deal for a developper installation, but the DB administrators will 100% sure cringe about this, and they'll be right. I think this should be discussed for later releases of NetArchive Suite, programmatically handling backwards compatibility during application initialization is, in my humble opinion and based on my experience, a serious design flaw.


Avant d'imprimer, pensez à l'environnement.
Consider the environment before printing this mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/netarchivesuite-users/attachments/20090415/bce616e1/attachment-0002.html>

More information about the NetarchiveSuite-users mailing list