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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Дата
Msg-id 15724.992482040@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal  ("Joe Conway" <joseph.conway@home.com>)
Список 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 по дате отправления:

Предыдущее
От: "Joe Conway"
Дата:
Сообщение: Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal
Следующее
От: "Joe Conway"
Дата:
Сообщение: Re: Re: [PATCHES] Fw: Isn't pg_statistic a security hole - Solution Proposal