Re: Lock conflict behavior?

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Lock conflict behavior?
Дата
Msg-id 1230003878.31604.17.camel@jdavis
обсуждение исходный текст
Ответ на Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: "Alex Hunsaker"
Дата:
Сообщение: Re: contrib/pg_stat_statements 1212
Следующее
От: Tom Lane
Дата:
Сообщение: Re: incoherent view of serializable transactions