Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Date
Msg-id 15724.992482040@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  ("Joe Conway" <joseph.conway@home.com>)
List pgsql-hackers
"Joe Conway" <joseph.conway@home.com> writes:
> I'll rework the patch per the above and resend.

Too late ;-).  I just finished ripping out the unneeded parts and
applying.

I made a few minor changes too, mostly removing unnecessary code
(you don't need to call nameout, everyone else just uses NameStr)
and trying to line up stylistically with other code.  One actual
bug noted: you were doing this in a couple of places:

+    tuple = SearchSysCache(RELOID, ObjectIdGetDatum(reloid), 0, 0, 0);
+    if (!HeapTupleIsValid(tuple)) {
+        elog(ERROR, "has_table_privilege: invalid relation oid %d", (int) reloid);
+    }
+
+    relname = NameStr(((Form_pg_class) GETSTRUCT(tuple))->relname);
+
+    ReleaseSysCache(tuple);

Since relname is just a pointer into the tuple, expecting it to still
be valid after you release the syscache entry is not kosher.  There are
several ways to deal with this, but what I actually did was to make use
of lsyscache.c's get_rel_name, which pstrdup()s its result to avoid this
trap.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joe Conway"
Date:
Subject: Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Next
From: "Joe Conway"
Date:
Subject: Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal