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

From Tatsuo Ishii
Subject Re: Lock conflict behavior?
Date
Msg-id 20081223.184542.70202895.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Lock conflict behavior?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Re: Lock conflict behavior?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > 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?

Right. I think we should check the permissions first too.

> 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.

In the scenario I mentioned, even a new connection cannot be made to
the database since the backend need to initialize relcache by reading
system catlogs with access share lock at the very eary stage in
strating up.
--
Tatsuo Ishii
SRA OSS, Inc. Japan


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Sync Rep: First Thoughts on Code
Next
From: Simon Riggs
Date:
Subject: Re: [PATCHES] Infrastructure changes for recovery (v8)