Subject | Re: [firebird-support] Re: Can we "Lock Down" Firebird to keep users from tampering with data? |
---|---|
Author | The Wogster |
Post date | 2006-03-14T02:34:19Z |
dbagregc wrote:
customer modifies the database (or hires a independant consultant, who
modifies it), and this causes a service call, then the customer should
have to pay for the service call, and then deal with the consultant
about restitution.
It's not hard to, run a comparison tool, to see that a database has an
improper modification to it, which means that the customer will be
billed for the service call, of fixing it. You can store a revision
code within the database to know which revision to compare it to.
W
> --- In firebird-support@yahoogroups.com, Alexandre Benson SmithSeems to be more of a mindset issue, then a database issue, if a
> <iblist@...> wrote:
>
>>Well...
>>
>>It is a hack !
>>
>>As Martijn said, there is no way to prevent SYSDBA to connect,
>
> unless
>
>>you use this hack, and I should add "use it at your own risk".
>>
>>
>>To undo, as always, you will can extract a metadata back-up.
>>Create a new database
>>pump the data from the old database.
>>
>>Anyway, I should tell you to try it on a database that you don't
>
> care
>
>>about, and see if if works, and if you can undo it if/when
>
> necessary.
>
>>see you !
>>
>>--
>>Alexandre Benson Smith
>>Development
>>THOR Software e Comercial Ltda
>>Santo Andre - Sao Paulo - Brazil
>>www.thorsoftware.com.br
>>
>
>
> Yea I could tell from the procedure that it is certainly a hack.
> Sadly we are desperate enough to get our database under OUR control
> that we might just use this hack if I can't find any specific danger
> with this. I would certainly prefer a cleaner solution, but from
> what I get from websites and Firebird forums is that the only other
> way to get what we want is to change the database we use. We like
> Firebird for because its free and we are a low budget company. We
> are in a bad situation and really need a way out so we might choose
> to go with this hack. If anyone knows of a better solution to keep
> everyone but our company from modifying data (without putting the
> databases at our site) I would LOVE to hear it.
>
> Thanks for your input. We and everyone else that might try this
> certainly need to realize that this is a hack and should be used
> with extreme caution. I will certainly try to find any downfalls to
> this before I make the switch, especially since our customers run
> their businesses using our software, and I would recommend the same
> to anyone else reading this.
>
customer modifies the database (or hires a independant consultant, who
modifies it), and this causes a service call, then the customer should
have to pay for the service call, and then deal with the consultant
about restitution.
It's not hard to, run a comparison tool, to see that a database has an
improper modification to it, which means that the customer will be
billed for the service call, of fixing it. You can store a revision
code within the database to know which revision to compare it to.
W