At 3/24/00 11:11 AM (Friday), Markus Kemper wrote:

From: "Markus Kemper" <mkemper@...>


> However, there are security holes which the database system can
> really help to close. For example, with any legitimate Interbase user
> account I can effectively crash my Interbase server by writing
> to a database until the disk fills up.

I believe that this 'crash' issue is resolved in 6.0 in that
we return an error when there is no disk space left on the
device.  Actually, I've never seen this crash but, rather
hang the client.

The problem I see is that with many embedded scenarios there is only one disk volume available and that if the free space disappears there is no place for work files such as the ones created for sorting results. Therefore, normal operations of the server are effectively halted, often with misleading error reports. An error report that there is no free disk space is the minimum I would expect. I might expect that as a result from an INSERT operation, but I would not readily expect it as a result from a SELECT (which included sorting via work files). I would, instead, expect the installation to reserve enough work space for such sorting.

I think whatever mechanism the server uses to switch between physical database files when one fills up could also be enhanced to *prevent* switching to a new file. This could be used as the basis of effectively limiting the database size to a predefined maximum. Then a small enhancement to the CREATE DATABASE syntax to denote a maximum size would do it. Elegant enough for you? <g>

> I can also create a new database any time I want

I would think that putting security on DDL would be a reasonable
enhancement.  (eg.  GRANT WRITE ON CREATE DATABASE TO xxxx).

That's the sort of thing I'm looking for! Same for creating tables which map to external files.