Re: Lock conflict behavior? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Lock conflict behavior?
Date
Msg-id 1230003878.31604.17.camel@jdavis
Whole thread Raw
In response to Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: Lock conflict behavior?
List 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



pgsql-hackers by date:

Previous
From: "Alex Hunsaker"
Date:
Subject: Re: contrib/pg_stat_statements 1212
Next
From: Tom Lane
Date:
Subject: Re: incoherent view of serializable transactions