Thread: Problem with recent permission changes commits
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua D. Drake wrote:
> 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?
Please forgive the use of 00 I have zero idea where that came from.
Joshua D. Drake
>
> Sincerely,
>
> Joshua D. Drake
>
>
- ---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
- --
=== 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
iD8DBQFG0u4eATb/zqfZUUQRAvHFAJwPFX7ozYHTYGqVMOF/YcX5599iDgCfT0rj
YkhQFn6JjHIooJooNA6eZdE=
=XeRq
-----END PGP SIGNATURE-----
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 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-----
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)