Обсуждение: Re: [BUGS] Probably a security bug in PostgreSQL rule system

Would someone comment on this?

---------------------------------------------------------------------------

Sergey N. Yatskevich wrote:
> At begin some citations from PostgreSQL documentation:
>
> <citation>
> 34.4. Rules and Privileges
>
> <skip/>
> Rewrite rules don't have a separate owner. The owner of a relation
> (table or view) is automatically the owner of the rewrite rules that are
> defined for it. The PostgreSQL rule system changes the behavior of the
> default access control system. Relations that are used due to rules get
> checked against the privileges of the rule owner, not the user invoking
> the rule. <note>This means that a user only needs the required
> privileges for the tables/views that he names explicitly in his
> queries</note>.
> <skip/>
> <note>This mechanism also works for update rules</note>. In the examples
> of the previous section, the owner of the tables in the example database
> could grant the privileges SELECT, INSERT, UPDATE, and DELETE on the
> shoelace view to someone else, but only SELECT on shoelace_log. The rule
> action to write log entries will still be executed successfully, and
> that other user could see the log entries. But he cannot create fake
> entries, nor could he manipulate or remove existing ones.
> </citation>
>
> Next -- test and it's output, that shows, that if view has INSERT,
> UPDATE and DELETE rules then _ANY_ user can insert, update and delete
> data in tables, that affected by this rules even user has no INSERT,
> UPDATE and DELETE privileges on view and table.
>
> This problem exists for at least 7.3.4 and 7.4.1 PostgreSQL versions.
>
> This is very strange and I'm not sure that I understand all true.
>
> P.S. Please help me solve this problem ASAP.
>
> P.P.S. Sorry for my bad english, but I hope You understand me.
>
> --
> Sergey N. Yatskevich <syatskevich@n21lab.gosniias.msk.ru>
> GosNIIAS

[ Attachment, skipping... ]

[ Attachment, skipping... ]

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Would someone comment on this?

This is fixed in CVS tip.

2004-01-13 22:39  tgl

    * src/backend/rewrite/: rewriteHandler.c (REL7_3_STABLE),
    rewriteHandler.c (REL7_4_STABLE), rewriteHandler.c: Revert
    ill-starred change of 13-Feb-02: it appeared to fix a problem of
    incorrect permissions checking, but in fact disabled most all
    permissions checks for view updates.  This corrects problems
    reported by Sergey Yatskevich among others, at the cost of
    re-introducing the problem previously reported by Tim Burgess.
    However, since we'd lived with that problem for quite awhile
    without knowing it, we can live with it awhile longer until a
    proper fix can be made in 7.5.

2004-01-14 18:01  tgl

    * src/: backend/commands/view.c, backend/executor/execMain.c,
    backend/executor/nodeSubplan.c, backend/nodes/copyfuncs.c,
    backend/nodes/equalfuncs.c, backend/nodes/outfuncs.c,
    backend/nodes/readfuncs.c, backend/optimizer/path/allpaths.c,
    backend/parser/analyze.c, backend/parser/parse_clause.c,
    backend/parser/parse_relation.c, backend/rewrite/rewriteDefine.c,
    backend/rewrite/rewriteHandler.c, include/catalog/catversion.h,
    include/executor/executor.h, include/nodes/parsenodes.h,
    include/parser/parse_clause.h, include/utils/acl.h: Fix
    permission-checking bug reported by Tim Burgess 10-Feb-03 (this
    time for sure...).  Rather than relying on the query context of a
    rangetable entry to identify what permissions it wants checked,
    store a full AclMode mask in each RTE, and check exactly those
    bits.  This allows an RTE specifying, say, INSERT privilege on a
    view to be copied into a derived UPDATE query without changing
    meaning.  Per recent discussion thread.  initdb forced due to
    change of stored rule representation.

            regards, tom lane