Re: Solution for RI permission problem

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Solution for RI permission problem
Date: 2000-10-01 18:28:55
Message-ID: Pine.BSF.4.10.10010011119530.10491-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Wed, 20 Sep 2000, Peter Eisentraut wrote:

> Here's what I've come up with to avoid "permission denied" errors when a
> RI trigger has to lock a PK table. Whenever the SELECT FOR UPDATE is
> executed I temporarily switch the current user id to the owner of the PK
> table. It's not the grand unified solution via setuid functions that was
> envisioned now and then, but it does the same conceptually. For a
> terminally elegant solution I can only suggest not using the SPI
> interface.
>
> I recommend this patch to be checked out by someone knowledgeable in the
> RI area.

It seems to be working on my system (and you don't need to give any access
to the pk table to the user).

With that, I do have a general question though. Are referential actions
supposed to be limited by the permissions of the user executing the query?
So, if you for example have write access on the pk table, but not to the
fk table, and there is a on cascade delete relationship, should that user
not be able to delete from the pk table?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-10-01 18:35:43 Re: Unruly rules
Previous Message Tom Lane 2000-10-01 15:24:45 Re: What do I need to be able to compile the source in Win32