|Subject||Re: [Firebird-Architect] Generator security - from Database trigger thread|
> The value of a variable increment is for making cluster wideI am not clear on exactly what you mean here. But even without
> unique sequences for replication. To do this right, you need
> to the database (or schema, if Firebird had schemas) to
> maintain both an increment and base where the next sequence
> is (generator * increment + base).
> It is far, far better to have the database engine do theI totally agree with this. The generator should be considered
> computation than to push it back into application.
as an object that returns appropriate "next" values. In theory
these need not even be sequential (if the generator was a more
intelligent object than it is now).
> I think this could easily be implemented in the Vulcan codeVery few do it intentionally (I wont say that no one does it,
> base, but some thought would need to be given future schema
> work, etc.
> I don't see any reason why sequences/generators shouldn't be
> under security control. On the other hand, I don't see any
> anyone in his right mind would expose his database to
> malicious users, either.
there are such concepts as "honey pots" in security). Here is
quote from something I was reading recently:
"accountants Ernst and Young, reports that 82 percent of the
worst frauds in 19992000 were committed by employees; nearly
half of the perpetrators had been there over five years, and
a third of them were managers"
(taken from "Security Engineering" by Ross Anderson).
There may be less incentive to be destructive than there is
to commit fraud, but then without knowing the applications use
of a generator you dont know if artificial increments to a
generator could be used to enable fraud.
(Replication is an interesting possibility here; could a record
be surreptitiously inserted/replaced/deleted from a database
system by changing a generator, performing some appropriate
action and then moving the generator back again. Later action
by the replication system could perhaps be fooled into
accepting changes that are not valid.)
> Creating and committing transactions in a tight loop isOf course there is very much to do in Firebird before it could
> probably a better way to bring a database to its knees,
> though I could probably come up with another hundred. But
> still, there's no reason that generators don't have security
> other than history.
be considered in anyway resilient against attacks from
authorised users. Generators are just a very obvious example,
and one that is fast and conceivably leaves very little trace
of what may have gone wrong or why (move the generator at a
critical time and then move it back again - who is to say how
all those records ended up out of sequence or failed to get