Обсуждение: Permission on tables

Поиск
Список
Период
Сортировка

Permission on tables

От
"Steven Cuthbertson"
Дата:
Question:

I have a server X with Apache & PHP and a server Y with Postgres. I had the
usual "permission denied" error while trying to execute a query pg_exec in
a simple php page. I googled around a bit and found a page suggesting that
I do this:

     grant ALL on mytable to PUBLIC;

Q: Is this dangerous? What is encompassed by "ALL"? Read? Write? Drop? There
are some extremely clever hackers out there and I have already seen what
they can do, without leaving them any loopholes...

Steven



________________________________________
Obtenga su direccion de correo en http://www.internetempresas.cl



Re: Permission on tables

От
"Nick Fankhauser"
Дата:
>      grant ALL on mytable to PUBLIC;
>
> Q: Is this dangerous? What is encompassed by "ALL"? Read? Write?

Sounds unwise to me, but I'm not a PHP-er.

In the Tomcat/Apache world, I can tell you that we generally grant select on
mytable to "www-data".
"www-data is the user that Apache runs as by default. I'd suggest finding
the Apache or PHP user & then granting only those privileges needed to only
that user.

Are you sure that you aren't just getting a more general rejection of your
connection due to problem in pg_hba? You mention that the servers are
separated. You could test the connectivity & authorization from X to Y by
trying (from X) psql -hY

regards,

-Nick

---------------------------------------------------------------------
Nick Fankhauser

    nickf@doxpop.com  Phone 1.765.965.7363  Fax 1.765.962.9788
doxpop - Court records at your fingertips - http://www.doxpop.com/


Re: Permission on tables

От
"Steven Cuthbertson"
Дата:
The user is running under tha name "apache". I tried creating the user "apache"
in pgsql and granting permission to that user, but that didn't work either,
which I find strange. It would seem that life is MUCH easier if Apache and
Postgres are installed on the same host, but that's not the case...

I'm reinstalling the apache machine now anyway, because I don't like the
way RH installed the rpm's

Steve

>-- Original Message --
>Reply-To: <nickf@ontko.com>
>From: "Nick Fankhauser" <nickf@ontko.com>
>To: "Steven Cuthbertson" <steven@tie.cl>,
>    <pgsql-admin@postgresql.org>
>Subject: Re: [ADMIN] Permission on tables
>Date: Fri, 26 Apr 2002 09:24:55 -0500
>
>
>
>>      grant ALL on mytable to PUBLIC;
>>
>> Q: Is this dangerous? What is encompassed by "ALL"? Read? Write?
>
>Sounds unwise to me, but I'm not a PHP-er.
>
>In the Tomcat/Apache world, I can tell you that we generally grant select
>on
>mytable to "www-data".
>"www-data is the user that Apache runs as by default. I'd suggest finding
>the Apache or PHP user & then granting only those privileges needed to only
>that user.
>
>Are you sure that you aren't just getting a more general rejection of your
>connection due to problem in pg_hba? You mention that the servers are
>separated. You could test the connectivity & authorization from X to Y by
>trying (from X) psql -hY
>
>regards,
>
>-Nick
>
>---------------------------------------------------------------------
>Nick Fankhauser
>
>    nickf@doxpop.com  Phone 1.765.965.7363  Fax 1.765.962.9788
>doxpop - Court records at your fingertips - http://www.doxpop.com/
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster



________________________________________
Obtenga su direccion de correo en http://www.internetempresas.cl



Re: Permission on tables

От
"Nick Fankhauser"
Дата:
Steve

Have you tried connecting just using psql to make sure you've got
authorization working over the network? It kind of sounds like that might
the the issue.

-Nick

> -----Original Message-----
> From: Steven Cuthbertson [mailto:steven@tie.cl]
> Sent: Friday, April 26, 2002 2:24 PM
> To: nickf@ontko.com; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Permission on tables
>
>
> The user is running under tha name "apache". I tried creating the
> user "apache"
> in pgsql and granting permission to that user, but that didn't
> work either,
> which I find strange. It would seem that life is MUCH easier if Apache and
> Postgres are installed on the same host, but that's not the case...
>
> I'm reinstalling the apache machine now anyway, because I don't like the
> way RH installed the rpm's
>
> Steve
>
> >-- Original Message --
> >Reply-To: <nickf@ontko.com>
> >From: "Nick Fankhauser" <nickf@ontko.com>
> >To: "Steven Cuthbertson" <steven@tie.cl>,
> >    <pgsql-admin@postgresql.org>
> >Subject: Re: [ADMIN] Permission on tables
> >Date: Fri, 26 Apr 2002 09:24:55 -0500
> >
> >
> >
> >>      grant ALL on mytable to PUBLIC;
> >>
> >> Q: Is this dangerous? What is encompassed by "ALL"? Read? Write?
> >
> >Sounds unwise to me, but I'm not a PHP-er.
> >
> >In the Tomcat/Apache world, I can tell you that we generally grant select
> >on
> >mytable to "www-data".
> >"www-data is the user that Apache runs as by default. I'd suggest finding
> >the Apache or PHP user & then granting only those privileges
> needed to only
> >that user.
> >
> >Are you sure that you aren't just getting a more general
> rejection of your
> >connection due to problem in pg_hba? You mention that the servers are
> >separated. You could test the connectivity & authorization from X to Y by
> >trying (from X) psql -hY
> >
> >regards,
> >
> >-Nick
> >
> >---------------------------------------------------------------------
> >Nick Fankhauser
> >
> >    nickf@doxpop.com  Phone 1.765.965.7363  Fax 1.765.962.9788
> >doxpop - Court records at your fingertips - http://www.doxpop.com/
> >
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ________________________________________
> Obtenga su direccion de correo en http://www.internetempresas.cl
>
>


Re: Permission on tables

От
Rasmus Mohr
Дата:
Granting total access is generally a bad idea. It requires that your
PHP-scripts/modules (or whatever) checks every request that access your
database to ensure only valid/allowed queries are made.

The "permission denied" reply suggests an Apache configuration error, not a
PostgreSQL related error.

--------------------------------------------------------------
Rasmus T. Mohr            Direct  :             +45 36 910 122
Application Developer     Mobile  :             +45 28 731 827
Netpointers Intl. ApS     Phone   :             +45 70 117 117
Vestergade 18 B           Fax     :             +45 70 115 115
1456 Copenhagen K         Email   : mailto:rmo@netpointers.com
Denmark                   Website : http://www.netpointers.com

"Remember that there are no bugs, only undocumented features."
--------------------------------------------------------------

> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org
> [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Nick Fankhauser
> Sent: Friday, April 26, 2002 4:25 PM
> To: Steven Cuthbertson; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Permission on tables
>
>
>
> >      grant ALL on mytable to PUBLIC;
> >
> > Q: Is this dangerous? What is encompassed by "ALL"? Read? Write?
>
> Sounds unwise to me, but I'm not a PHP-er.
>
> In the Tomcat/Apache world, I can tell you that we generally
> grant select on
> mytable to "www-data".
> "www-data is the user that Apache runs as by default. I'd
> suggest finding
> the Apache or PHP user & then granting only those privileges
> needed to only
> that user.
>
> Are you sure that you aren't just getting a more general
> rejection of your
> connection due to problem in pg_hba? You mention that the servers are
> separated. You could test the connectivity & authorization
> from X to Y by
> trying (from X) psql -hY
>
> regards,
>
> -Nick
>
> ---------------------------------------------------------------------
> Nick Fankhauser
>
>     nickf@doxpop.com  Phone 1.765.965.7363  Fax 1.765.962.9788
> doxpop - Court records at your fingertips - http://www.doxpop.com/
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>