Hi Adam,

Like many things the severity of the problem is dependent on
your own particular situation.

If you only use generators for creation of surrogate primary
key values then the worst that is going to happen if the
generator is reset is that your app will hit a duplicate key
problem. Highlighting the issue and demanding that you fix
it.

If, like me, you now use a single generator for primary key
values on all your tables then things could get a bit more
vague. If the situation remains the same as it would have
been with multiple generators then there is no real issue, it
may simply take a bit longer until the problem is discovered.
However, if any of your code requires that identifiers from
multiple tables remain unique, then a problem could arise if
the generator is reset.

If you use generators to create auditable number sequences (eg:
invoice numbers and the like) then the problem could be more
serious to you. I dont use generators for this purpose, partly
for security but mostly so that I can use batch processes and
locking to ensure an unbroken sequence.

In many respects it is the ability for any authenticated user
to create database objects (and even databases) that concerns
me more. Such capabilities make the entire computer on which
Firebird is operating vulnerable to DoS. Such things can (and
should be) partly protected against in the operating system
(using quotas etc) but it is still a nasty hole if you ever
think about making Firebird visible to the Internet. In such
cases you would (hopefully) not be compiling passwords into
exes and you would be trying to ensure that you use aliases to
protect actual disk location details and the restricted
location stuff in the configuration file. These would all
help, but IMO there needs to be features available to better
manage this side of the server security.

--
Geoff Worboys
Telesis Computing


Friday, February 25, 2005, 11:43:08 AM, you wrote:

> Wow, those are worrying holes. I am fortunate in that the
> nature of our application means that physical file security
> is not something we really need to worry too much about.
> The second one is not quite so major, but still a definite
> problem. The first one is really bad.

> Adam


>> - Change generator values. There is no security checking on
>> generators, and changing generator values would upset many
>> database applications.
>>
>> - Create other database objects and start filling them with
>> data (thus filling disks and perhaps impacting performance)
>>