Thread: Deployment of PostgreSQL Applications

Hi everyone,

I'm working on a (sorry) closed source application which consists of Java
servlets, beans, and client applications talking to a postgresql database.
Now, lets say I'm interested in bundling this all together and selling it to
customers.

2 questions:

1) Is it legal to bundle Postgresql with another commercial application,
assuming the database will have to be significantly reconfigured and tuned?
(at the application level, not the source code level)  I read over the
licenses I could find on the site and they seemed to imply that the answer
was yes, but I'd like to reaffirm that.

2) More importantly, is it possible to prevent a customer from peeking into
said database once it is deployed on their machine?  A large part of what
makes my application proprietary is the data model in the database, and it'd
be tough to maintain a competative edge when everyone can see exactly how I
do things in the database by logging into their postgres account, adding
some users and changing permissions on their machine.  I really need to make
sure the database is bulletproof before I can begin deployment.

I' very new to postgresql and unix system administration in general, never
having secured a system or played with permissions much in the past.  Any
advice would be greatly appreciated.

Thanks,
Mike

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

> 2) More importantly, is it possible to prevent a customer from peeking
into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and
it'd
> be tough to maintain a competative edge when everyone can see exactly how
I
> do things in the database by logging into their postgres account, adding
> some users and changing permissions on their machine.  I really need to
make
> sure the database is bulletproof before I can begin deployment.

    If the people that have your application have physical access (or even
remote superuser access) to the machine on which the database resides then
there is little you could do to prevent a knowledgeable person from getting
anything he/she wanted from the database, circumventing the PostgreSQL
security measures by reading the information right off the disk... I don't
know how hard or easy it would be to get meaningful information this way but
it's always going to be possible when people have superuser/physical access
to the machine.

-Mitch

"Mike Arace" <mikearace@hotmail.com> writes:

> 1) Is it legal to bundle Postgresql with another commercial application,
> assuming the database will have to be significantly reconfigured and tuned?
> (at the application level, not the source code level)  I read over the
> licenses I could find on the site and they seemed to imply that the answer
> was yes, but I'd like to reaffirm that.

Yes, the PG license is BSD, so you can do that.  IANAL, but there
shouldn't be any problem.

> 2) More importantly, is it possible to prevent a customer from peeking into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and it'd
> be tough to maintain a competative edge when everyone can see exactly how I
> do things in the database by logging into their postgres account, adding
> some users and changing permissions on their machine.  I really need to make
> sure the database is bulletproof before I can begin deployment.

Fat chance.  Give it up.

Think about it.  It's *their* machine.  They have root.  The PG file
format is, if not documented, reverse-engineerable from freely
available sources.  But they don't even need to do that, since they
can just 'su' to the Postgres user and do whatever.

Even with Oracle or another proprietary DB I don't think you could do
what you want to do, unless you sell them the box, keep root on it
yourself, never let them touch it, and make them go through a web/XML
interface for everything, in which case PG will do just as well.

If you want to prevent them peeking, use legal/contractual means,
because technical ones won't work.

Have fun.

-Doug
--
Free Dmitry Sklyarov!
http://www.freesklyarov.org/

We will return to our regularly scheduled signature shortly.

On Fri, Aug 31, 2001 at 08:59:53AM -0400,
  Mike Arace <mikearace@hotmail.com> wrote:
>
> 2) More importantly, is it possible to prevent a customer from peeking into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and it'd
> be tough to maintain a competative edge when everyone can see exactly how I
> do things in the database by logging into their postgres account, adding
> some users and changing permissions on their machine.  I really need to make
> sure the database is bulletproof before I can begin deployment.

I don't think that the above is going to be technically possible if the code
is running on machines controlled by your users.

My guess is that either the database has to be run on your machines or
you need some contract that legally prevents your customers from telling
anyone about your data model.

On Fri, 31 Aug 2001, Mike Arace wrote:

> 1) Is it legal to bundle Postgresql with another commercial application,
> assuming the database will have to be significantly reconfigured and tuned?
> (at the application level, not the source code level)  I read over the
> licenses I could find on the site and they seemed to imply that the answer
> was yes, but I'd like to reaffirm that.
Yes.

> 2) More importantly, is it possible to prevent a customer from peeking into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and it'd
> be tough to maintain a competative edge when everyone can see exactly how I
> do things in the database by logging into their postgres account, adding
> some users and changing permissions on their machine.  I really need to make
> sure the database is bulletproof before I can begin deployment.
In general, answer is no. You could try to fake it by not giving customer
password for the database, but they could always poke around your app's
files, or boot postgres single-user. If you change postgres code that it
wouldn't boot singleuser, they can download postgres and recompile it,
removing that restriction.

Its 'security-through-obscurity'. You can prevent them from doing certain
things, but the fact of the matter is, they have the physical access to
the machine, and thus can read raw data on disk to find out what you are
doing.

-alex

> 1) Is it legal to bundle Postgresql with another commercial
> application,
> assuming the database will have to be significantly
> reconfigured and tuned?
> (at the application level, not the source code level)  I read
> over the
> licenses I could find on the site and they seemed to imply
> that the answer
> was yes, but I'd like to reaffirm that.

Yes.

> 2) More importantly, is it possible to prevent a customer
> from peeking into
> said database once it is deployed on their machine?  A large
> part of what
> makes my application proprietary is the data model in the
> database, and it'd
> be tough to maintain a competative edge when everyone can see
> exactly how I
> do things in the database by logging into their postgres
> account, adding
> some users and changing permissions on their machine.  I
> really need to make
> sure the database is bulletproof before I can begin deployment.

No way.

Vadim

On Fri, Aug 31, 2001 at 08:59:53AM -0400, Mike Arace wrote:
> 2 questions:

I'll let someone else handle the first one.

> 2) More importantly, is it possible to prevent a customer from peeking into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and it'd
> be tough to maintain a competative edge when everyone can see exactly how I
> do things in the database by logging into their postgres account, adding
> some users and changing permissions on their machine.  I really need to make
> sure the database is bulletproof before I can begin deployment.

It's not really possible to hide a database schema. Once you've logged in,
all the information is there describing all the table and fields. This data
is used by the database itself to process your queries.

You could try to prevent logins into the database but if someone has root on
that machine that's really not hard to get around. At worst they could read
the database files directly.

Seriously though, I'm wondering about your situation, who owns the data in
the database? If it's your customer then shouldn't they have access to it?
You talk about the data model. Is it really such a special data model that
nobody else has thought of it before?

P.S. Fortunatly, you can't patent database schemas last time I checked so at
least the world is safe from that.

--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
> It would be nice if someone came up with a certification system that
> actually separated those who can barely regurgitate what they crammed over
> the last few weeks from those who command secret ninja networking powers.

> > 2) More importantly, is it possible to prevent a customer from peeking
into
> > said database once it is deployed on their machine?

    ROT13 it, then threaten them with the DMCA.

  (Yes, that was a joke.)

steve

Not only is it impossible to keep systems
administrators from being able to "peek" into your
database, but those kind of controls tend to tick us
off.  After all, we get paid for watching out for
systems, developers that make our lives difficult do
not get our business.

What happens if we already have a PostgreSQL server
and want to use your software with it?  Or worse yet,
what happens when we install your software and it
installs another version of PostgreSQL on the machine
that conflicts with another version we already have
installed (they want to use the same port for
example)?

Normal systems administrators are not interested in
stealing your data model, but they probably will be
interested in reindexing tables manually, scripting a
backup, and other such tasks that require having
access to the table.  If you deny them access to the
database containing *their* data, then they will look
around for alternatives.  What's more, companies like
having access to the data model so that they can
integrate the software with other packages that they
might have.  Or does your software do *everything*.

Your competitors will be able to "borrow" your data
model no matter what you do.  There's no sense
aggravating your customers.

--- Mitch Vincent <mvincent@cablespeed.com> wrote:
> > 2) More importantly, is it possible to prevent a
> customer from peeking
> into
> > said database once it is deployed on their
> machine?  A large part of what
> > makes my application proprietary is the data model
> in the database, and
> it'd
> > be tough to maintain a competative edge when
> everyone can see exactly how
> I
> > do things in the database by logging into their
> postgres account, adding
> > some users and changing permissions on their
> machine.  I really need to
> make
> > sure the database is bulletproof before I can
> begin deployment.
>
>     If the people that have your application have
> physical access (or even
> remote superuser access) to the machine on which the
> database resides then
> there is little you could do to prevent a
> knowledgeable person from getting
> anything he/she wanted from the database,
> circumventing the PostgreSQL
> security measures by reading the information right
> off the disk... I don't
> know how hard or easy it would be to get meaningful
> information this way but
> it's always going to be possible when people have
> superuser/physical access
> to the machine.
>
> -Mitch
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the
> unregister command
>     (send "unregister YourEmailAddressHere" to
majordomo@postgresql.org)


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

On Fri, Aug 31, 2001 at 10:15:59AM -0400, Mitch Vincent wrote:
> > said database once it is deployed on their machine?  A large part of what
> > makes my application proprietary is the data model in the database, and
> > sure the database is bulletproof before I can begin deployment.
>
>     If the people that have your application have physical access (or even
> remote superuser access) to the machine on which the database resides then
> there is little you could do to prevent a knowledgeable person from getting
> anything he/she wanted from the database, circumventing the PostgreSQL

And as a note, this is not limited to PostgreSQL either.  The same
reasoning applies to Oracle, DB2, MS-SQL, and so on.

However, you may consider this:  some people view proprietary data models
like this as a negative thing, not a positive one.

Many times we've had to reverse engineer the data storage stuff because the
provided interface simply did not provide enough flexibility to accomplish
what was needed.  For those that had everything documented, those
enhancements went MUCH faster and much smoother.  For those that were
"hidden," life was hell.  And often those products were dropped.

mrc
--
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

> 2) More importantly, is it possible to prevent a customer from peeking into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and it'd
> be tough to maintain a competative edge when everyone can see exactly how I
> do things in the database by logging into their postgres account, adding
> some users and changing permissions on their machine.  I really need to make
> sure the database is bulletproof before I can begin deployment.
>
> I' very new to postgresql and unix system administration in general, never
> having secured a system or played with permissions much in the past.  Any
> advice would be greatly appreciated.

As I've seen other people say, you most certainly can't.  The only thing
that you could do would be to obscure the fact that it's postgres.
Change the port number to the same as and Oracle installation...  do a
search and replace for the workd 'postgres' and change it to 'myapp'.
Just becareful you don't shoot yourself in the food.  ;)  -sc

--
Sean Chittenden

On Friday 31 August 2001 05:59 am, you wrote:
> Hi everyone,
>
> I'm working on a (sorry) closed source application which consists of Java
> servlets, beans, and client applications talking to a postgresql database.
> Now, lets say I'm interested in bundling this all together and selling it
> to customers.
>
> 2 questions:
>
> 1) Is it legal to bundle Postgresql with another commercial application,
> assuming the database will have to be significantly reconfigured and tuned?
> (at the application level, not the source code level)  I read over the
> licenses I could find on the site and they seemed to imply that the answer
> was yes, but I'd like to reaffirm that.

I think so. The copyright notice might need to be somewhere... but BSD
lisence is pretty forgiving.

>
> 2) More importantly, is it possible to prevent a customer from peeking into
> said database once it is deployed on their machine?  A large part of what
> makes my application proprietary is the data model in the database, and
> it'd be tough to maintain a competative edge when everyone can see exactly
> how I do things in the database by logging into their postgres account,
> adding some users and changing permissions on their machine.  I really need
> to make sure the database is bulletproof before I can begin deployment.
>

It is not difficult to find myriad essays and casual opinions attacking such
a business model, but that wasn't your question (hey, if you have something
new it could certainly be justified to keep it secret a while). It's just a
matter of time anyway (open source now or later?).

Every piece of software *could* be reverse engineered; it sounds to me like
you want to hold it off long enough to make a buck or two (return on
investment, hopefully). Some simple stuff can go a long way towards this
goal. Maybe add a very small layer to all disk reads in postgres that uses a
weak (but fast) encryption method before it gets processed (maybe XOR
everything with alternating values?). For a quick method try making a wrapper
for the system read/write calls and do a search/replace on the source. That
way, the data on disk is unreadable. The encryption would be breakable by any
experienced programmer, but I think you already know that can happen anyway.
It all depends on how much time you want to spend.

One comment brought up the point that you may want to include automatic
maintainence (vacuum, reindexing) so the customers don't get too frustrated
:). Oh, and do use a different port as well as completely nonconflicting
setup.

> I' very new to postgresql and unix system administration in general, never
> having secured a system or played with permissions much in the past.  Any
> advice would be greatly appreciated.
>

I am sure you'll like it more the more you learn. Hopefully some of your
development efforts will be to improve postgres or some other project later
on (and contibuting it, of course).

Regards,
    Jeff Davis

> Thanks,
> Mike
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster