Re: Two-phase commit security restrictions

Поиск
Список
Период
Сортировка
От David Garamond
Тема Re: Two-phase commit security restrictions
Дата
Msg-id 416D5EAD.8050004@zara.6.isreserved.com
обсуждение исходный текст
Ответ на Two-phase commit security restrictions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Two-phase commit security restrictions  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Список pgsql-hackers
Heikki Linnakangas wrote:
> What kind of security restrictions do we want for prepared transactions? 
> Who has the right to finish a transaction that was started by user A? At 
> least the original user, I suppose, but who else?
> 
> Under what account is the transaction manager typically going to run? A 
> separate TM account perhaps?
> 
> Do we need a "GRANT TRANSACTION" command to give permission to finish 
> 2PC transcations?
> 
> Another approach I've been thinking about is to allow anyone that knows 
> the (user-supplied) global transaction identifier to finish the 
> transaction, and hide the gids of running transactions from regular 
> users. That way, the gid acts as a secret token that's only known by the 
> transaction manager, much like the cancel key.

Personally I prefer the last. It should be infeasible to crack as long 
as the gid is long enough (e.g. sufficiently random 128bit value or 
more) and the channel between the TM and Postgres is secure.

The problem is, we cannot guarantee that a TM will generate a good 
random gid, or even a long enough one. (But then a good TM should assume 
that RM doesn't have any protection on global transactions and thus 
generate a good "secret-like" gid).

Does the XA standard regulate about this security issue?

-- 
dave



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Two-phase commit security restrictions
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: plans for bitmap indexes?