Re: Fw: Isn't pg_statistic a security hole - Solution Proposal - Mailing list pgsql-patches

From Joe Conway
Subject Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Date
Msg-id 013c01c0ebdc$75214120$0705a8c0@jecw2k1
Whole thread Raw
In response to Re: Fw: Isn't pg_statistic a security hole - Solution Proposal  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Fw: Isn't pg_statistic a security hole - Solution Proposal  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Thanks for the detailed feedback, Tom. I really appreciate the pointers on
my style and otherwise. Attached is my next attempt. To summarize the
changes:

- changed usesysid back to Oid. I noticed that the Acl functions all treated
usesysid as an Oid anyway.

- changed function names to has_user_privilege_name_name,
has_user_privilege_name_id, etc

- trimmed down test script, added variety (some privs granted, not all), and
added bad input cases (this already paid off -- see below)

- replaced has_table_privilege(int usesysid, char *relname, char *priv_type)
  with
  AclMode convert_priv_string (text * priv_type_text)

- changed
     if (result == 1) {
         PG_RETURN_BOOL(FALSE);
         . . .
   to
     if (result == ACLCHECK_OK) {
        PG_RETURN_BOOL(TRUE);
         . . .
- removed #define PRIV_INSERT "INSERT\0", etc from acl.h

One item of note -- while pg_aclcheck *does* validate relname for
non-superusers, it *does not* bother for superusers. Therefore I left the
relname check in the has_table_privilege_*_name() functions. Also note that
I skipped has_priv_r3.diff -- that one helped find the superuser/relname
issue.

I hope this version passes muster ;-)

-- Joe


Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] Support for %TYPE in CREATE FUNCTION