Re: Lock conflict behavior?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Lock conflict behavior?
Date: 2008-12-23 03:44:38
Message-ID: 1230003878.31604.17.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2008-12-22 at 17:14 +0900, Tatsuo Ishii wrote:
> Also, it seems that an attacker could do a denial service attack if he
> could open session A and B, since other users on session C or
> following sessions will be blocked.

LOCK TABLE checks the permissions before attempting to acquire the lock,
is there a reason that ALTER TABLE doesn't?

Even if they don't have any rights to the table at all (not even
SELECT), there are still other problems. For instance, the user could
just wait for a long running query (or VACUUM) and issue the ALTER TABLE
at that time.

I know we don't make any guarantees about preventing denial-of-service
attacks from users that can connect, but if possible we should be
consistent about checking the permissions.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-23 04:44:17 Re: incoherent view of serializable transactions
Previous Message Alex Hunsaker 2008-12-23 03:33:01 Re: contrib/pg_stat_statements 1212