Skip site navigation (1) Skip section navigation (2)

Re: Fw: Isn't pg_statistic a security hole - Solution Proposal

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Joe Conway <joe(at)conway-family(dot)com>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Date: 2001-06-01 15:04:10
Message-ID: Pine.LNX.4.30.0106011651210.757-100000@peter.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Joe Conway writes:

> The patch applies cleanly against cvs tip. One item I was not sure about was
> the selection of the OID value for the new function. I chose 1920 for no
> other reason that the highest OID in pg_proc.h was 1909, and this seemed
> like a safe value. Is there somewhere I should have looked for guidance on
> this?

~/pgsql/src/include/catalog$ ./unused_oids
3 - 11
352 - 353
1713 - 1717
1910 - 16383

> > ANSI SQL 92 does not have any functions defined for retrieving privilege
> > information. It does, however define an "information schema" and
> "definition
> > schema" which among other things includes a TABLE_PRIVILEGES view.

Yes, that's what we pretty much want to do once we have schema support.
The function you propose, or one similar to it, will probably be needed to
make this work.

> >   select has_privilege('postgres', 'pg_shadow', 'select');
> >
> > where
> >   the first parameter is any valid user name
> >   the second parameter can be a table, view, or sequence
> >   the third parameter  can be 'select', 'insert', 'update', 'delete', or
> > 'rule'

This is probably going to blow up when we have the said schema support.
Probably better to reference things by oid.  Also, since things other than
relations might have privileges sometime, the function name should
probably imply this; maybe "has_table_privilege".

Implementation notes:

* This function should probably go into backend/utils/adt/acl.c.

* You don't need PG_FUNCTION_INFO_V1 for built-in functions.

* I'm not sure whether it's useful to handle NULL parameters explicitly.
  The common approach is to return NULL, which would be semantically right
  for this function.

Peter Eisentraut   peter_e(at)gmx(dot)net

In response to


pgsql-hackers by date

Next:From: Thomas SwanDate: 2001-06-01 15:15:42
Subject: Feature request : Remove identifier length constraints
Previous:From: Mike MascariDate: 2001-06-01 14:45:03
Subject: RE: Access statistics

pgsql-patches by date

Next:From: Ian Lance TaylorDate: 2001-06-01 16:59:07
Subject: Re: AW: [HACKERS] Re: Support for %TYPE in CREATE FUNCTION
Previous:From: Michael SamuelDate: 2001-06-01 13:11:13
Subject: Re: Re: Support for %TYPE in CREATE FUNCTION

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group