Hi Geoff.

You are right, I didn't even think of storage quota issues, that
could get a little nasty. I was thinking in terms of the application
working. If you create additional objects in the database, apart from
the resources they take up, it won't actually stop anything from
working.

On the other hand, if you reset my generators on me, I will get
primary key violations. Of course they are captured and handled
somewhat gracefully, but it would stop the application working until
you fixed it. Worse still, they could potentially increment the
generator to an amount say a couple of hundred shy of the 64 bit
limit, and before long there will be an overflow, which would be a
pain to fix. It would also not be immediately noticable.

Adam


--- In firebird-support@yahoogroups.com, Geoff Worboys <geoff@t...>
wrote:

> 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)
> >>