Re: Overcoming SELECT ... FOR UPDATE permission restrictions

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Overcoming SELECT ... FOR UPDATE permission restrictions
Date: 2018-04-16 17:12:45
Message-ID: 667c0861-3375-a537-ae09-5e8b293ebf50@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

13.04.2018 18:55, Tom Lane wrote:
> Although this is arguably a security bug, I'm not sure we should
> back-patch it. The consequences seem relatively minor, and the
> behavioral change carries a significant risk of breaking applications
> that worked as-intended up to now. Thoughts?
The worst scenario (with the current system views) I could think of is:
user=> CREATE VIEW pgg AS SELECT * FROM pg_group;
BEGIN TRANSACTION; SELECT * FROM pgg FOR UPDATE; SELECT pg_sleep(60);
ROLLBACK;
and the parallel operation:
admin=> DROP ROLE testrole;
hangs for one minute.
But admin can observer the locks and kill the offending backend so it's
hardly a critical issue.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Verite 2018-04-16 18:27:59 Re: Proposal: Adding json logging
Previous Message Liudmila Mantrova 2018-04-16 16:48:47 Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug