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: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Date: 2001-06-03 03:22:44
Message-ID: 013c01c0ebdc$75214120$0705a8c0@jecw2k1 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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: test_has_table_priv.out
Description: application/octet-stream (8.7 KB)
Attachment: test_has_table_priv.sql
Description: application/octet-stream (6.2 KB)
Attachment: has_priv_r4.diff
Description: application/octet-stream (12.0 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-06-03 15:18:20
Subject: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:From: Gavin SherryDate: 2001-06-03 02:10:09
Subject: Re: Full text searching, anyone interested?

pgsql-patches by date

Next:From: Peter EisentrautDate: 2001-06-03 15:18:20
Subject: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:From: Tom LaneDate: 2001-06-02 23:26:12
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal

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