Mailing List Archive


Back to the month index Back to the list index
rasmus@mail1.bellglobal.com
Wed, 15 Jan 1997 09:18:53 -0500 (EST) 

From: rasmus@mail1.bellglobal.com
Date: Wed, 15 Jan 1997 09:18:53 -0500 (EST)
Subject: Re: [mSQL] 2.0 - can it cache results?
Message-Id: <ML-2.3.853337933.7174.rasmus@inet-dev>

> I don't think you can do that in ANSI terms. The SELECT INTO creates the
> table.

Ok, that isn't a big problem. The client app will just need to check
first then. Although it would be nice if the select into could return
something directly to avoid the race conditions that would occur if the
check and the create were non-atomic.

> I'd have to disagree. mSQL is available over the net so I could, in
> theory, trash any machine on the Net running mSQL 2.0 by sending it bogus
> SELECT INTO queries. That is a remote denial of service attack and is
> something CERT would be keen to advise people of.

This makes no sense to me. A site would have to actively make their mSQL
setup publically available. CERT should be all over NFS then. You can
share your entire file systems with the world if you wish and people can
fill up your disk.

> Anything like that is riddled with problems. Lets say I write an app
> that decides to keep the oldest 20 tmp tables hanging around (the APP is
> web based BTW). Suddenly I get 21 people hit the box at the same time
> and boom! it's game over because I've blown away a tmp table that was
> probably still in use.

I would probably solve that by using the "least used" approach to deleting
tables. Whenever a table is used I update its timestamp. I also maintain
a count of the number of tables I have. When it comes time to delete a table
I check the timestamps and delete the table that hasn't been used for the
longest time. If I make sure that I never any table accessed within the
last 10 minutes for example, then I should be safe. To get around a massive
denial of service attack, I'd probably have an upper bound of cache tables.
Once I hit that I simply stop caching until some of the tables get deleted
by the "least used" scheme.

> Sure, the easy (and ANSI) option is to punt the entire problem into the
> lap of the user and let them worry about it. If I can find a way to
> manage this in the server itself it makes using this feature a lot easier
> and much safer. I'm all for making the server as easy to use as
> possible. Data management complexity should be in the server rather than
> in the clients. It makes writing good client code much easier.

As long as this "ease of use" feature doesn't make the solution less
flexible, that is fine.

-Rasmus
--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to "unsubscribe" to msql-list-request@bunyip.com. Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!