Subject | SYSDBA and passwords |
---|---|
Author | petesouthwest |
Post date | 2005-02-24T18:52:17Z |
Hi
I am developing a application for distribution that stores data in a
firebird database. The app is being developed using Delphi with IBO
components and uses Inno setup scripts to create setup files for a
user. The Firebird server is being installed silently, as part of my
apps installation, if the end user does not already have it
installed.
I was intending to change the SYSDBA password from the default so
that other developers/hackers would not be able to access the user's
data, so I have just begun reading about database security. But am
rather confused. From my understanding of what I have read, the
usernames and passwords for all databases are dealt with by the
firebird server, rather than individual databases, and stored in a
security.fdb.
Can someone explain what happens to my app and its associated fb
database if an end user changes the SYSDBA password? Surely my app
will no longer be able to communicate with its database as the app
has been compiled with the default password?
Does my app have to create a new user, and use this new username to
communicate with the database?
Some of this article: http://firebird.sourceforge.net/index.php?
op=doc&sub=contrib&id=fb_meta_security seems to contradict my
understanding of what I have read.
One part says
"Removing SYSDBA access
At various times people have suggested that removing SYSDBA access
to a database could be the solution. The idea behind it is that,
when the database is moved to a new server where the SYSDBA password
is known, it will not help the person because SYSDBA does not have
access anyway. Some have reported limited success in this respect by
creating an SQL role name of SYSDBA and making sure it does not have
access to the database objects."
Is the SYSDBA meant to be removed after the application has been
installed on the end users system? Wont that stop any other
applications from communicating with their respective databases if
they are using the SYSDBA username?
Thanks for taking the time to explain this to me.
Pete
I am developing a application for distribution that stores data in a
firebird database. The app is being developed using Delphi with IBO
components and uses Inno setup scripts to create setup files for a
user. The Firebird server is being installed silently, as part of my
apps installation, if the end user does not already have it
installed.
I was intending to change the SYSDBA password from the default so
that other developers/hackers would not be able to access the user's
data, so I have just begun reading about database security. But am
rather confused. From my understanding of what I have read, the
usernames and passwords for all databases are dealt with by the
firebird server, rather than individual databases, and stored in a
security.fdb.
Can someone explain what happens to my app and its associated fb
database if an end user changes the SYSDBA password? Surely my app
will no longer be able to communicate with its database as the app
has been compiled with the default password?
Does my app have to create a new user, and use this new username to
communicate with the database?
Some of this article: http://firebird.sourceforge.net/index.php?
op=doc&sub=contrib&id=fb_meta_security seems to contradict my
understanding of what I have read.
One part says
"Removing SYSDBA access
At various times people have suggested that removing SYSDBA access
to a database could be the solution. The idea behind it is that,
when the database is moved to a new server where the SYSDBA password
is known, it will not help the person because SYSDBA does not have
access anyway. Some have reported limited success in this respect by
creating an SQL role name of SYSDBA and making sure it does not have
access to the database objects."
Is the SYSDBA meant to be removed after the application has been
installed on the end users system? Wont that stop any other
applications from communicating with their respective databases if
they are using the SYSDBA username?
Thanks for taking the time to explain this to me.
Pete