|Subject||RE: [Firebird-Architect] Generator security - from Database trigger thread|
>> Credits for problems when anyone reset the generator shouldThis has always been, and continues to be, a significant flaw
>> go for who reset and/or for who designed it to be resettable.
in the security of Firebird. (This along with the lack of
ability to restrict creation of metadata.)
> Give me a break, fella. That was a long time ago and I didn'tI hope you are NOT suggesting a user should be able to move a
> know any better. It was obvious within a year of the V3
> release that allowing them to be resettable was a major mistake.
> I've gotten smarter since -- Netfrastructure/Falcon don't let
> anyone move a sequence backward. Forward, yet, backwards, no.
generator forward by an arbitrary amount? This is effectively
the same as allowing it to be reset back to zero. I just move
the generator forward to its upper limit.
The ONLY secure solution to the generator issue is to be able
to secure all access - as with other metadata objects. Secure
the generator and then explicitly give access via GRANT to (for
example) a trigger.
Being able to differentiate between a standard increment and
non-standard increment (except that we dont seem to store the
increment as part of the generator definition) could be a mid-
way step. You could then allow read or read/write access to
the generator. Read access would allow "next value"
(gen_id(xxx, 1)) but only write access could alter sequence.
And what exactly is a non-standard increment? I have replication servers and
10 as the basic increment