[Tfug] Trusting DBMS results

[Bexley Hall]

Hi, Paul,

> > I'm *heavily* integrating a DBMS into an application.
> > I.e., things that I would often "hard code" in the
> > application have been moved into the database.
> > 
> > As a matter of principle, I "never trust inputs".
> > (regardless of whether they come from users or
> > "sensors", etc.)
> > 
> > But, how pedantic should I treat the data that "I"
> > (i.e., my application) has placed in the database?
> > 
> > For example, tables that are "written during manufacture"
> > (and never altered, in theory, at run time)... should I
> > have faith in their sanity?  I.e., should I treat the
> > DBMS as a reliable medium?  Or, one that is "suspect"?
> > 
> > Note that I implicitly trust values that I "store" in RAM
> > from my computations.  Should the integrity of the DBMS
> > be considered on a par with that?  I.e., assume the DBMS
> > has mechanisms to detect and repair problems just like
> > ECC memory catches alpha particles, etc.
> 
> I, like you, validate everything the user gives me. If it
> is a configuration file, I insure that what is given to me
> is sane. I do very little programming where the user has
> actual real-time input but on the occasions that I do I
> validate the data as completely as possible. For simple
> tasks, the code for validation can often be larger than the
> actual work being done.

Exactly.  And, doing it at run time -- often *repeatedly*
at run time (i.e., if the data is not cached in the
application... to ease resource requirements) -- is really
the worst (performance) time to have to do this!

> Programming is as much philosophical as it is technical; as
> much art as it is science.

<grin>  I consider it far more art than science (or, at the very
least, a science that needs a lot more effort *documenting* its
"rules"/maxims.

> Any programmer worth his/her salt
> is asking the same questions you are asking and have come to
> some philosophical conclusion on how to proceed. The very
> fact that it is not always a technical answer, though, will
> cause there to be more than one right answer.

Of course.  Horses for courses.
 
> With that said here is *my* "right" answer...
> 
> I also use databases fairly extensively in the code that I
> write. In my mind, the database is an extension of the
> programming code itself.

Yes, that's my attitude.  In many cases, I'm not using the database
to store "data" that are *processed* by the application as much as
data that are *part* of the application.  (subtle but significant
semantic difference).  I'm a *huge* fan of table driven routines.
So, I'm just taking the leap of moving those tables out of ROM
and into a DBMS.  :-/

> Is it possible for a person to alter the database? Possibly.
> That would show some level of sophistication of the person 
> though as well as authenticated access.

Yes.  That, actually, is part of the appeal of this approach
as it lets me make huge changes to the system (from outside)
without having to "reprogram" it.

However, that "person" is *me* (or my agent).

I'm taking the approach of validating the data ON ENTRY into
the database (i.e., "on update"). Since this is done very
infrequently, I can move the costs there without burdening
the application's performance.

And, presumably, I will be very *careful* when making those
changes!  ;-)

But, if I "guarantee" that the data going into the database is
good, is it wise to rely on a "component" as complex as a DBMS
to accurately *maintain* that data -- and provide it to me in
an unaltered form on demand?

(i.e., we have informally concluded that it is acceptable to
rely on the disk system to give us back the data that we stored
on it... I think most RDBMS's are considerably more complex
than almost all disk filesystems!)

> That same person may also use a hex editor and patch
> my compiled code.

Exactly.

> The code itself can be though of as a
> database containing logic. Access to the program code and
> the database is also restricted to trusted people or
> programs. So, with that in mind, I treat the data that I put
> into the database the same way I treat the code that I put
> into my program. It is golden. I trust it. Data that comes
> from anywhere else must be validated.

Agreed.  The only issue is how "reliable" a component the
DBMS is...

> Now with that said, most (all?) of the code I write is not
> being held to a standard that must pass a strict security
> test. My programs are not so interesting as to draw the
> attention of a hacker. My programs generally run within a
> secured environment which would have to be breached before
> my code could even be executed. Were that not the case,
> though, I would be concerned with the data in the database
> as well as the code I was running. I would use checksums and
> security keys and encrypted data. When paranoia gets to that
> level you need to be concerned about everything and in this
> I have no experience. Only you can decide where on the
> paranoia scale your program lies.

Access to the database isn't readily available.  Nor is it
easy to access the code itself (this is an appliance so you
can't just slip in a new "boot floppy" and have the processor
executing code that *you* want -- presumably to subvert any
mechanisms I have put in place).  Of course, there is nothing
that prevents a malicious user from deliberately *breaking*
the device.  But, I don't care, in that case.  "You broke it,
of COURSE it doesn't work 'correctly' anymore!"  :>

I'm mainly concerned that it works "as advertised" with the
design decisions that I make.

> That is the long answer. The short answer is that I trust
> the data that I put into the database to be valid because to
> get there it would have been validated on the front end.
> 
> There is also a saying that I learned a long tome ago. It
> says "You can't make anything foolproof because
> fools are so ingenious."

I'd heard it as "... damn clever idiots!"  :>

To summarize, would you agree with the following:

Rely on the DBMS and the data within it.  If that
component sufers from a faulty *implementation*,
fix/replace it.

--don