DB design document

[linas@linas.org]

Hi Derek,

I want to say up front that I'm enjoying this conversation.  I say
this because my response may seem like flame bait at times.  So
please don't interpret any terseness or stridency below as an attack.

--linas


It's been rumoured that Derek Atkins said:
> 
> <linas@linas.org> writes:
> 
> > Lets reanalyse the requirements. You want security. Why? to run over
> > the open internet?  If you're running over the open internet, then
> 
> The whole concept of a trusted network assumes that you can trust
> everyone who has access to that network.  It also assumes that you
> trust every machine sitting on that network.  It also assumes that you
> trust the people running the network.  It also assumes that none of
> your machines can be turned against you.  It also assumes that none of
> these assumptions can be broken.

This is indeed the standard definition of a trusted network.

> So, you're sitting at home on your home LAN.  Let's assume you're
> connected to the internet via DSL or CableModem.  

DSL/cable modem is not a trusted network. Its open network.
Yes, the kid down the block is probably snooping your packets.

> Also, how secure is your home machine?  

If your home machine is 0wn3d, then you can't trust it, and no amount
of encryption can fix that, period.  If your 0wn3d, hacker can write
a linux kernel extension to grab whatever data from wherever, and
that's that, and yes, there have been cases of 'wild' kernel
extensions (beleived to actually be authored by nsa, but that's
another story...).

> Let's take a small business example...

Normally, a machine with finacial data, esp. in a business, should
not be connected to the net, period.   I'm sure there are mom&pop
business that violate this.  

There are ecommerce machines that need to shove order-processing
thorugh various databases, these are usually protected with multiple
layers of firewalls and audit proceedures.

Finally, there are payroll machines, these should not be the same as
the order/inventory machines, for the security reason.

You are right, running encrypted data over 'trusted' network might 
help discourage employee fraud.   As long as you've also taken
measures to avoid clear-text passwords, etc. 

> So, do you trust all your employees and co-workers?  How do you know
> what the employee in the next office is doing or thinking?  Are they
> disgruntled?  Maybe they want to know how much you're making?  Perhaps
> they are being paid by a competitor?  Do you trust the people actually
> running the network?  Who maintains your routers?

None of the people listed above should have either network or
physical access to the machines containing financial data. 
This is kind-of network admin 101 stuff, so I'm not sure why we
discuss it.  

Note also: if are a publically traded corporation, or a startup that 
needs to be audited because the VC asks for it, the auditors will 
review and question your firewall config, the network topology and
the physical/network access thing.  You will fail the audit if you
get this wrong.

On the other hand, chumps rule the world ...

> I'm not proposing that we re-invent, 

I'm just concerned abou building complex, hard-to-maintain systems
that don't have a clear scope of requirements that are to be solved.

> investigate using ONC RPC as the marshalling system, which is much
> less overhead than CORBA, 

Its not obvious to me that any RPC has lower overhead than corba.
I'm tempted to beleive the opposite.

Besides, remember that corba was invented to solve many of the evils
and lack of function that rpc didn't/couldn't do.

> have ONC RPC available) so we wont have to worry about portability.

all platforms have corba as well.

> I've just grabbed a book on CORBA, and I'm looking at information on
> ORBit.  I've certainly not bought into to one camp or another.


> Actually, it's not that hard.  We've been working towards this on the
> list.  For example, we've been discussing the Query API, which is one
> such data-store API.  We would still need to discuss the APIs to
> obtain the lists of accounts, groups, etc.  And we also need to
> discuss the data write APIs, and data cache conherency (events &
> notifications?)

This is one reason I nominated corba.  Many (but not all) of the api 
questions melt away, with an 'obvious' answer.   

Note events & notifications should work in corba, & I don't know how
to do them with RPC, except as polls.

> provided that we do limit the scope of where SQL enters the rest of
> GnuCash.

Yes, its important for me that we don't wake up one day and find 
sql code scattered throughou the gnucash engine in some adhoc way.
That would be fatal.


--linas