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

From David Garamond
Subject Re: Two-phase commit security restrictions
Date
Msg-id 416E07F2.6010301@zara.6.isreserved.com
Whole thread Raw
In response to Re: Two-phase commit security restrictions  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Responses Re: Two-phase commit security restrictions
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Fix breakage in hashjoin from recent
Next
From: Oliver Jowett
Date:
Subject: Re: Two-phase commit security restrictions