Robert Treat wrote:
> On Sat, 2003-07-26 at 21:31, Gavin Sherry wrote:
>>>> - Read only transactions, bringing a greater level of security to web and
>>>> enterprise applications by protecting data from modification.
>> This should be removed. Even though I added it to the press release,
>> I've just realised it's not really a security measure against SQL
>> injection since injected code can just specify 'SET TRANSACTION READ
>> WRITE'. We should still mention it, but not as a security measure.
> Aside from spec compliance, whats the bonus for having it then? Or put
> a better way, why/when would I want to use this?
If I am writing a "report program" that isn't supposed to do any
updates to anything, then I would be quite happy to set things to
READ-ONLY as it means that I won't _accidentally_ do updates.
It's like adding a pair of suspenders to your wardrobe. You can
_always_, if you really try, get your pants to fall down, but this
provides some protection.
I would NOT call it a "security" provision, as it is fairly easily
defeated using SET TRANSACTION.
But it's a nice discipline...
We can tell people:
"When you are writing report programs, start them off by setting
transactions to be READ-ONLY. That means that you won't modify data
by accident."
That's a useful sort of "Best Practice," for those organizations that
are into that sort of thing.
--
let name="cbbrowne" and tld="libertyrms.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)