Re: [GENERAL] cgi with postgres
От | Ron Chmara |
---|---|
Тема | Re: [GENERAL] cgi with postgres |
Дата | |
Msg-id | 38826A4B.8AA18BCE@opus1.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] cgi with postgres (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [GENERAL] cgi with postgres
|
Список | pgsql-general |
Alfred Perlstein wrote: > * Ron Chmara <ron@Opus1.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
В списке pgsql-general по дате отправления: