Re: [PATCH] Fix segmentation fault and infinite loop in jsonb_{plperl,plpython} - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Fix segmentation fault and infinite loop in jsonb_{plperl,plpython}
Date
Msg-id 969559.1781646393@sss.pgh.pa.us
Whole thread
In response to Re: [PATCH] Fix segmentation fault and infinite loop in jsonb_{plperl,plpython}  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: [PATCH] Fix segmentation fault and infinite loop in jsonb_{plperl,plpython}
List pgsql-hackers
Aleksander Alekseev <aleksander@tigerdata.com> writes:
>> I thought about that, but I'm not sure how to build a bulletproof
>> check at reasonable (ie, near zero) cost.  We could detect the example
>> case where an object refers directly to itself, by noticing that "in"
>> doesn't change in one iteration.  But I'm pretty sure it's possible to
>> build reference loops involving two or more Perl objects, and those
>> would fool such a check.

> I was thinking about depth-first search where we store our current
> path in a set. If the visited node is already in the set then the
> graph has loops.

> This is not exactly cheap but the complexity is proportional to the
> cost of the serialization so I think we should be fine.

No, it'd be O(N^2) for an N-deep reference chain.  Admittedly,
realistic use-cases would never have more than a couple of layers of
indirection.  But this whole exercise is to guard against adversarial
inputs, I think.  I don't really want to add cycles and complexity to
make our behavior a bit more friendly in cases that nobody is going
to get into unless they are trying to break the database.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ben Mejia
Date:
Subject: Re: [PATCH] vacuumdb: Add --exclude-database option
Next
From: Robert Haas
Date:
Subject: Re: use of SPI by postgresImportForeignStatistics