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

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

From: "Joe Conway" <joe(at)conway-family(dot)com>
To: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Date: 2001-06-02 22:14:41
Message-ID: 00bd01c0ebb1$6ca8e280$0705a8c0@jecw2k1 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
> Thanks for the feedback! To summarize the recommended changes:
>
> - put function into backend/utils/adt/acl.c.
> - remove PG_FUNCTION_INFO_V1
> - mark 'proisstrict' in pg_proc
> - rename to has_table_privilege()
> - overload the function name for 6 versions (OIDs 1920 - 1925):
>     -> has_table_privilege(text username, text relname, text priv)
>     -> has_table_privilege(oid usesysid, text relname, text priv)
>     -> has_table_privilege(oid usesysid, oid reloid, text priv)
>     -> has_table_privilege(text username, oid reloid, text priv)
>     -> has_table_privilege(text relname, text priv)    /* assumes
> current_user */
>     -> has_table_privilege(oid reloid, text priv)    /* assumes
current_user
> */
>

Here's a new patch for has_table_privilege( . . .). One change worthy of
note is that I added a definition to fmgr.h as follows:

   #define PG_NARGS             (fcinfo->nargs)

This allowed me to use two of the new functions to handle both 2 and 3
argument cases. Also different from the above, I used int instead of oid for
the usesysid type.

I'm also attaching a test script and expected output. I haven't yet looked
at how to properly include these into the normal regression testing -- any
pointers are much appreciated.

Thanks,

-- Joe


Attachment: has_priv_r2.diff
Description: application/octet-stream (12.1 KB)
Attachment: test_has_table_priv.out
Description: application/octet-stream (40.8 KB)
Attachment: test_has_table_priv.sql
Description: application/octet-stream (27.3 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-06-02 23:26:12
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:From: Tom LaneDate: 2001-06-02 21:11:00
Subject: Re: Re: [GENERAL] +/- Inf for float8's

pgsql-patches by date

Next:From: Tom LaneDate: 2001-06-02 23:26:12
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:From: Bruce MomjianDate: 2001-06-02 16:39:41
Subject: Re: Re: AW: [HACKERS] Re: Support for %TYPE in CREATE FUNCTION

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