Re: [GENERAL] cgi with postgres

From: Ron Chmara <ron(at)Opus1(dot)COM>
To: Alfred Perlstein <bright(at)wintelcom(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Jeff MacDonald <jeff(at)hub(dot)org>, pgsql-general(at)hub(dot)org
Subject: Re: [GENERAL] cgi with postgres
Date: 2000-01-17 01:03:14
Message-ID: 38826A4B.8AA18BCE@opus1.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alfred Perlstein wrote:
> * Ron Chmara <ron(at)Opus1(dot)COM> [000116 16:18] wrote:
Snip_> Of security items.....
> All these options don't take into account that perhaps you don't
> want people _on the same box_

Well, I assumed that web clients, using cgi, was the "Subject:",
so I didn't adrdress it. :-)

> to be able to even read arbitrary
> things from your database. Sure you can protect the tables from
> modification via postgresql's internal ACL system, however what
> if you wish to deny read access as well?
> For this you need a file with an ACL prevents other _local users_
> from reading it.

Hm. If they cannot read the file, how do they read it for access? :-)
If they _can_ read a component for access, you already have an
item to be eploited, again, it's about finding _balance_ in one's
access needs. The only secure server is a non-existant one.

> This is _not_ security through obscurity, this is basic ACL control.

Which is insecure to attacks from anything that uses it. :-)

> Again, figure a way to 'protect' your shadow password database
> without relying on an external auth server.

Completely protected? On a single server? Can't be done. Relatively
protected? Sure. But it's not "secure", it's "relatively secure".

Snip_>
> >. For
> > vanilla access, they would *know* where the server is, and *have* one
> > pasword....
> > So
> > you have to balance how much security you need versus how many
> > hoops you want to make, as setting up 20+ boxes, in series, to
> > use a SELECT statement, may be a bit absurd for your application.

>> I'd say these are good examples of security through absurdity,
> interesting to research, but as implied from the responce times
> of this system: not usable.
> sorry, :)

Perhaps you missed the point behind starting with something
extremely insecure (such as a single ACL, as you propose, and I started
with something as inherently insucre as that) , and scaling up to
absurdly slow, hard to break, but still insecure: There's no such
thing as a secure server. So you have to find balance, knowing that
whatever you do is insecure in *some* way, and relatively secure
in other ways.

-Ronabop

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message moebius 2000-01-17 01:34:17 Re: [GENERAL] Debian php3+postgresql unable to connect
Previous Message Alfred Perlstein 2000-01-17 00:31:31 Re: [GENERAL] cgi with postgres