Re: Two-phase commit security restrictions - Mailing list pgsql-hackers

From David Garamond
Subject Re: Two-phase commit security restrictions
Date
Msg-id 416D5EAD.8050004@zara.6.isreserved.com
Whole thread Raw
In response to Two-phase commit security restrictions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Two-phase commit security restrictions
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Two-phase commit security restrictions
Next
From: Josh Berkus
Date:
Subject: Re: plans for bitmap indexes?