SEO

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I just saw this in the weekly news:

Restrict pg_relation_size to relation owner, pg_database_size to DB
owner, and pg_tablespace_size to superusers. Perhaps we could
weaken the first case to just require SELECT privilege, but that
doesn't work for the other cases, so use ownership as the common
concept.

This is a problem. Our analytics software purposefully does not use a
super user, you are going to force the use of superusers with admin and
monitoring tools.

Of course this may be m00t if I am able to modify the GRANT?

Sincerely,

Joshua D. Drake


- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0ujyATb/zqfZUUQRAhZSAJ4rhSGd6Cm/d6WU8JnZfXZ81axXtgCeKAfd
soW+ppLFZK/5UcBuQqrlNlM=
=u1jX
-----END PGP SIGNATURE-----

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Mon, Aug 27, 2007 at 08:08:34AM -0700, Joshua D. Drake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I just saw this in the weekly news:
>
> Restrict pg_relation_size to relation owner, pg_database_size to DB
> owner, and pg_tablespace_size to superusers. Perhaps we could
> weaken the first case to just require SELECT privilege, but that
> doesn't work for the other cases, so use ownership as the common
> concept.
>
> This is a problem. Our analytics software purposefully does not use a
> super user, you are going to force the use of superusers with admin and
> monitoring tools.

Well, you could always create a wrapper function that is SECURITY
DEFINER...

Honestly, I have to wonder if it'd be best to just restrict all those
functions to superuser-only. They tend to be rather slow to run since
they have to stat each file, so I'm worried about what kind of load that
would present on a loaded system.
--
Decibel!, aka Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFG0xwEdO30qud8SkgRAh2UAJ9JV/OQ7KSs6xOAF2PJh7okG3mC4gCg0+Ox
F0Tlr2q6/D8Pm+uslIl5wxI=
=ecCF
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Decibel! wrote:
> On Mon, Aug 27, 2007 at 08:08:34AM -0700, Joshua D. Drake wrote:

>> This is a problem. Our analytics software purposefully does not use a
>> super user, you are going to force the use of superusers with admin and
>> monitoring tools.
>
> Well, you could always create a wrapper function that is SECURITY
> DEFINER...

Well from my perspective, it is nice that we don't have to install
anything except a non privileged user to get what we need.

Really, if we change this we might as well also block all access to
information_schema, the net effect is the same.

Joshua D. Drake





- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG0x75ATb/zqfZUUQRAq/EAKCPH+Sk4+yZJ5s01nxL5RdDJI+gPwCfU1TQ
PEHLy4ca6rivBquF+59MCes=
=RBpF
-----END PGP SIGNATURE-----

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, Aug 27, 2007 at 11:59:05AM -0700, Joshua D. Drake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Decibel! wrote:
> > On Mon, Aug 27, 2007 at 08:08:34AM -0700, Joshua D. Drake wrote:
>
> >> This is a problem. Our analytics software purposefully does not use a
> >> super user, you are going to force the use of superusers with admin and
> >> monitoring tools.
> >
> > Well, you could always create a wrapper function that is SECURITY
> > DEFINER...
>
> Well from my perspective, it is nice that we don't have to install
> anything except a non privileged user to get what we need.
>
> Really, if we change this we might as well also block all access to
> information_schema, the net effect is the same.

Info_schema should be checking permissions the same as, say, \d does.

What I think we *really* need is a set of views for people to use that
have appropriate security, instead of using pg_catalog directly.
--
Decibel!, aka Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFG0yeJdO30qud8SkgRAgAnAJ9jgiZVH45x0NTWJ2twKC 2O9pc6EQCgshtA
Jh7245CVeUM6STZx6U/LgPU=
=CC0P
-----END PGP SIGNATURE-----