Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "KaiGai Kohei" <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Date: 2008-11-07 20:12:50
Message-ID: 603c8f070811071212o156bb2e9x309041574992a40f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Foreign Key deletions could be handled correctly if you treat them as
> updates. If we have the following example
>
> TableA
> security_context=y value=2 fk=1
>
> TableB
> security_context=x value=1
>
> TableA refers to TableB. Context x cannot see context y.
>
> So if somebody with context x tries to delete value1 from TableB, they
> will be refused because of a row they cannot see. In this case the
> correct action is to update the tuple in TableB so it now has a
> security_context = y. The user with x cannot see it and can be persuaded
> he deleted it, while the user with y can still see it.

It seems odd for a low-privilege user to be able to elevate the
privilege of a tuple above their own privilege level. I also don't
believe that the privilege level is a total order, which might make
this something of a sticky wicket. But those are just my thoughts as
a non-guru.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-11-07 20:12:52 Re: [RRR] Tests citext casts
Previous Message Alvaro Herrera 2008-11-07 20:10:29 Re: Re: [BUGS] libpq does not manage SSL callbacks properly when other libraries are involved.