Re: [HACKERS] Query cancel and OOB data

> 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > I was trying to avoid the
> > 'magic cookie' solution for a few reasons:
> 
> > 	1) generating a random secret codes can be slow (I may be wrong)
> 
> Not really.  A typical system rand() subroutine is a multiply and an
> add.  For the moment I'd recommend generating an 8-byte random key with
> something like
> 
> 	for (i=0; i<8; i++)
> 		key[i] = rand() & 0xFF;
> 
> which isn't going to take enough time to notice.

Actually, just sending a random int as returned from random() is enough.
random() returns a long here, but just cast it to int.

> 
> The above isn't cryptographically secure (which means that a person who
> receives a "random" key generated this way might be able to predict the
> next one you generate).  But it will do to get the protocol debugged,
> and we can improve it later.  I have Schneier's "Applied Cryptography"
> and will study its chapter on secure random number generators.

Yes, that may be true.  Not sure if having a single random() value can
predict the next one.  If we just use on random() return value, I don't
think that is possible.

> 
> > 	2) the random key is sent across the network with a cancel
> > request, so once it is used, it can be used by a malcontent to cancel
> > any query for that backend.
> 
> True, if you have a packet sniffer then you've got big troubles ---
> on the other hand, a packet sniffer can also grab your password,
> make his own connection to the server, and wreak much more havoc
> than just issuing a cancel.  I don't see that this adds any
> vulnerability that wasn't there before.

Yes.

> 
> > 	3) I hesitate to add the bookkeeping in the postmaster and libpq
> > of that pid/secret key combination.  Seems like some bloat we could do
> > without.
> 
> The libpq-side bookkeeping is trivial.  I'm not sure about the
> postmaster though.  Does the postmaster currently keep track of
> all operating backend processes, or not?  If it does, then another
> field per process doesn't seem like a problem.

Yes.  The backend does already have such a per-connection structure, so
adding it is trivial too.

> 
> > 	4) You have to store the secret key in the client address space,
> > possibly open to snooping.
> 
> See password.  In any case, someone with access to the client address
> space can probably manage to send packets from the client, too.  So
> "security" based on access to the client/backend connection isn't any
> better.

Yep.

> 
> > This basically simulates OOB by sending a message to the postmaster,
> > which is always listening, and having it send a signal, which is
> > possible because they are owned by the same user.
> 
> Right.
> 
> Maybe we should look at this as a fallback that libpq uses if it
> tries OOB and that doesn't work?  Or is it not a good idea to have
> two mechanisms?

You have convinced me.  Let's bag OOB, and use this new machanism.  I
can do the backend changes, I think.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)