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.

- Heikki

Wed, 13 Oct 2004 18:13:20 +0300 (EEST)
Heikki Linnakangas <hlinnaka@iki.fi>
Two-phase commit security restrictions
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> 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?

I would say the original user, any superuser, and nobody else.  This
conforms to Postgres' usual practices (compare to the right to DROP
an object).

> Do we need a "GRANT TRANSACTION" command to give permission to finish 2PC 
> transcations?

Overkill.

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

Security-by-obscurity isn't really security, and I think that hiding the
GIDs is likely to make things noticeably more painful to manage.

			regards, tom lane

Wed, 13 Oct 2004 12:35:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Two-phase commit security restrictions 
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


Wed, 13 Oct 2004 23:58:21 +0700
David Garamond <lists@zara.6.isreserved.com>
Re: Two-phase commit security restrictions
On Wed, Oct 13, 2004 at 11:58:21PM +0700, David Garamond wrote:
> Heikki Linnakangas wrote:

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

So it is possible for a user connected to the DB to send random commit
or cancel commands, just in case she happens to hit a valid GID?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La realidad se compone de muchos sueï¿½os, todos ellos diferentes,
pero en cierto aspecto, parecidos..." (Yo, hablando de sueï¿½os erï¿½ticos)


Wed, 13 Oct 2004 15:20:22 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: Two-phase commit security restrictions
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?

Do we not require transaction initiation and conclusion to happen in the 
same session, so that the transaction could be considered a 
session-local object?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


Wed, 13 Oct 2004 21:18:51 +0200
Peter Eisentraut <peter_e@gmx.net>
Re: Two-phase commit security restrictions
On Wed, 13 Oct 2004, Peter Eisentraut wrote:

> 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?
>
> Do we not require transaction initiation and conclusion to happen in the
> same session, so that the transaction could be considered a
> session-local object?

No. After we have told the transaction manager that the transaction has 
been successfully prepared, we must not lose it. Otherwise we break the 
atomicity of the global transaction.

Successful preparation is a promise to the TM that we will be able to 
finish the 2nd phase commit later, no matter what.

- Heikki

Wed, 13 Oct 2004 22:26:47 +0300 (EEST)
Heikki Linnakangas <hlinnaka@iki.fi>
Re: Two-phase commit security restrictions
Heikki Linnakangas wrote:

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

Doesn't this break recovery? The TM needs to find all outstanding GIDs 
for a particular resource.

I guess if we treated (database + authenticated user) as the equivalence 
key for XAResources (XAResource.isSameRM() in Java-speak) it might work. 
Then only transactions initiated by the current user need to be visible.

Either way, it seems necessary to have some way for recovery to get the 
set of GIDs that are in doubt and the current user has permission to 
resolve. Otherwise the TM is going to get confused when it tries to 
resolve a transaction that appears to be needing recovery but it does 
not have permission to resolve.

-O

Thu, 14 Oct 2004 10:26:06 +1300
Oliver Jowett <oliver@opencloud.com>
Re: Two-phase commit security restrictions
Oliver Jowett wrote:
> Heikki Linnakangas wrote:
> 
>> 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.
> 
> Doesn't this break recovery? The TM needs to find all outstanding GIDs 
> for a particular resource.

Isn't it the TM's job to remember all the outstanding GIDs? But it would 
be nice to ask each RM too, I guess.

-- 
dave

Thu, 14 Oct 2004 09:45:31 +0700
David Garamond <lists@zara.6.isreserved.com>
Re: Two-phase commit security restrictions
David Garamond wrote:
> Oliver Jowett wrote:
> 
>> Heikki Linnakangas wrote:
>>
>>> 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.
>>
>>
>> Doesn't this break recovery? The TM needs to find all outstanding GIDs 
>> for a particular resource.
> 
> 
> Isn't it the TM's job to remember all the outstanding GIDs?

At a minimum it has to know how to contact all resources that might be 
involved in in-doubt transactions. Whether it also knows all the GIDs 
seems to depend somewhat on the TM's transaction log implementation 
(e.g. it may not be logging start-of-prepare).

My concern was more along the lines of how to implement Java's 
XAResource interface, which has 'Xid[] XAResource.recover(int flags)' 
i.e. the TM does not request recovery for specific transactions, it 
requests recovery for a whole resource. I think this is just a mapping 
of how the underlying XA system works, so presumably it'll be a problem 
for other XA-based APIs too.

-O

Thu, 14 Oct 2004 16:14:06 +1300
Oliver Jowett <oliver@opencloud.com>
Re: Two-phase commit security restrictions
Alvaro Herrera wrote:
>>>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.
> 
> So it is possible for a user connected to the DB to send random commit
> or cancel commands, just in case she happens to hit a valid GID?

It is not essentially different from someone trying to bruteforce a 
password. A 128bit value like a random GUID is as strong as a 16 char 
password comprising ASCII 0-255 characters. And I would argue that this 
is _not_ security through obscurity. Security through obscurity is 
relying on unpublished methods/algorithms. This is not.

But I understand that everybody seems to be against this idea.

-- 
dave

Thu, 14 Oct 2004 12:00:34 +0700
David Garamond <lists@zara.6.isreserved.com>
Re: Two-phase commit security restrictions
David Garamond wrote:

>> So it is possible for a user connected to the DB to send random commit
>> or cancel commands, just in case she happens to hit a valid GID?
> 
> 
> It is not essentially different from someone trying to bruteforce a 
> password. A 128bit value like a random GUID is as strong as a 16 char 
> password comprising ASCII 0-255 characters. And I would argue that this 
> is _not_ security through obscurity. Security through obscurity is 
> relying on unpublished methods/algorithms. This is not.

You have no guarantees that GIDs generated by an external transaction 
manager are random. An obvious implementation is TM-identity plus 
sequence number, which is very predictable.

-O

Thu, 14 Oct 2004 18:21:23 +1300
Oliver Jowett <oliver@opencloud.com>
Re: Two-phase commit security restrictions