|
[
Permalink
| « Hide
]
Dmitry Yemanov added a comment - 13/Mar/08 11:54 AM
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).
I want obtain the error "invalid transaction handle" when the non-public transaction handles uses with public API
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. 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 Dmitry, could it be a real problem we will take measures to fix. But I see no problems here at all.
|
||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Access to children of multiple transaction