Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Catacomb] dbms.c proposed changes



I'm in favor of making the database code more secure -- you certainly
identify a very significant security hole!

The database independent layer sounds good to me, though I will note that
discussions I've had with people who have developed document management
systems indicate that for performance reasons they quickly get to the point
where the optimize heavily for specific databases, including making use of
functions executing in the DB.  Since we're  focusing on just getting things
working, we don't have to worry so much about performance. But, the limited
performance profiling that was done last Winter indicates that Catacomb's
performance is really slow, orders of magnitude off what commercial doc.
mgmt. systems achieve. For Catacomb to be taken seriously, we'll eventually
need to address performance.

So, what I want is a database-independent layer that leaves the door open
for database-specific optimization. I'm not sure what this would look like.

- Jim

> -----Original Message-----
> From: catacomb-admin@webdav.org [mailto:catacomb-admin@webdav.org]On
> Behalf Of Chris Knight
> Sent: Wednesday, September 04, 2002 9:51 AM
> To: catacomb@webdav.org
> Subject: [Catacomb] dbms.c proposed changes
>
>
>   In reviewing the code for Catacomb, I realized that there is a
> (common) security problem with the dbms.c file. namely that using
> sprintf with strings to generate SQL queries can be broken by a
> well-designed value (For example, if you manage to pass a url that
> looked something like "'; drop database repos;" the query would result
> in a valid drop database statement being executed, quite deadly! The
> best solution is to use the string escaping mechanism provided by
> MySQL's C API, but it's a bit clunky to insert into the existing code.
>
> This issue, coupled with my desire to connect Catacomb to other RDBMS's
> (particularly PostgreSQL) had me thinking last night about coming up
> with a more generic, JDBC-style interface. I've attached a first pass at
> a .h file for such a thing.  I could probably have the code written for
> this by end-of-day today and all of the queries in dbms.c should be
> changed to use this mechanism. I'm sure there will be more functions
> (dbms_set_X) and wrappers for results retrieval.
>
> Sound good?
>
> Alternatives include libdbi.sourceforge.net (although it doesn't provide
> the automatic escaping of parameters and you can't pre-fill parameters,
> we might be able to influence the project to include such features) or
> possibly ODBC interfaces...
>