Excerpts from Greg Smith's message of vie dic 16 11:19:52 -0300 2011: > On 12/16/2011 08:42 AM, Robert Haas wrote: > > the proposed patch would potentially result - in the extremely > > unlikely event of a > > super-fast PID wraparound - in someone cancelling a query they > > otherwise wouldn't have been able to cancel. > > > > So how might this get exploited? > > -Attach a debugger and put a breakpoint between the check and the kill
If you can attach a debugger to a backend, you already have the credentials to the user running postmaster, which we assume to be a "game over" condition. I guess a more interesting exploitation would be to do this until the killing backend randomly wins the race condition against a dying backend and a new one starting up; this would require very rapid reuse of the PID, plus very rapid startup of the new proces. I think we already assume that this is not the case in other code paths, even on systems that randomly (instead of sequentially) assign PIDs. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
