Commented by: @dyemanov

Do you want sub-transactions to have non-public handles? Or do you have problems with the range scan hack? The latter is by design, FWIW (although there's no guarantee you will be so lucky under high load).

Commented by: @ibprovider

I want obtain the error "invalid transaction handle" when the non-public transaction handles uses with public API

Commented by: @AlexPeshkoff

What is described here is not a vulnerability. I'm agreed that API should be able to protect from crazy errors (like NULL pointer when non-NULL expected, etc.). But what you suggest here (scan range of handles from M to N) sooner looks like attack on remote site, not use of API, when you work with your _own_ set of transactions. Why in the hell would any user try to find and use subhandles of his own, legally started transaction? If he wants to break his application inside API call, there are a lot of much simpler ways to do it - just use not NULL, but invalid pointer:)
This range scan will never let him to gain accees to the resources which he cannot reach without it. Therefore I suggest to close this request.

Commented by: @ibprovider

The test for this problem has about 100 lines

Correction of this problem (I think) will be have less than 100 lines
- append the property 'is_public_resources' to BaseHandle
- correct translate<> template function. Append the argument public_resource_only. Or create new translate<> template

Or [more private case]
- append the property 'is_public_resource' to Transaction
- create (specialization?) translate<> template for Transaction

Commented by: @AlexPeshkoff

Dmitry, could it be a real problem we will take measures to fix. But I see no problems here at all.