Re: [GENERAL] Postgres CGI Security Problem
От | darcy@druid.net (D'Arcy J.M. Cain) |
---|---|
Тема | Re: [GENERAL] Postgres CGI Security Problem |
Дата | |
Msg-id | m0z4zNs-00006FC@druid.net обсуждение исходный текст |
Ответ на | Postgres CGI Security Problem (Chris Hardie <chris@summersault.com>) |
Список | pgsql-general |
Thus spake Chris Hardie > The situation: I have one machine with general user access. Some users > (including myself) own a postgres database. Some users (including myself) > use postgres as a back-end for CGI applications, using the Postgres.pm > module for Perl. This requires that user "nobody" (or www, or whomever) > have read/write access to my database. > > The problem: While it's very handy that I can write CGI scripts that can > read/write my database, it's a security problem. Other users` CGI scripts > will also make use of the "nobody" identity to access the database, which > means they can potentially read/write the data in my database if they > wanted to. > > The fix: You tell me. It would seem to involve a "setuid" of sorts for > how the httpd process accesses the postgres database. Here's how I handle it. Run a separate web server as the database owner. Put all the scripts into a separate directory and make it the document root. If running Apache, put the following directive into srm.conf. UserDir disabled Otherwise other users can write their own scripts and access your database. You might also consider creating a user especially for running this app. That way you can grant just enough privileges to them to make the page work. I also use .htaccess files to allow admin and user access by putting the admin and user files into separate directories. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
В списке pgsql-general по дате отправления: