Subject | Re: [firebird-support] Is it possible to do a backup with a regular user? |
---|---|
Author | Helen Borrie |
Post date | 2005-07-16T02:31:46Z |
At 08:13 PM 15/07/2005 +0000, you wrote:
Owner can do a backup.
Follow the good advice and DO NOT deploy databases that were created by
SYSDBA. Always appoint a special user that will have administrative rights
in the database you are going to deploy (for backups, metadata changes,
object privileges, et al.) and log in to your development environment as
this user when creating databases, objects, privileges, and so on.
When you deploy your system, create this special user on the deployment
site. Advise the management of the site to take the usual precautions with
this admin user's login credentials that they would take with
SYSDBA's. SYSDBA of course can vaporise any database; an Owner is
restricted to wrecking only databases that it owns.
Actually, since any user can restore a backup using the -c[reate] switch,
you can change the database owner by recreating from the backup while
logged in as another user. The trap here, of course, is that changing the
owner of the database does not change the ownership of the objects inside
the database. To do the right thing, you will need to rebuild the database
from scratch, i.e. from script, while logged in as the user which you want
to be the owner.
./heLen
>I have a form on my application that allows the user to do the backupContrary to what someone else said, in fact either SYSDBA or the database
>of a database. This form calls 'gbak' to do this task, but i see i
>need to be SYSDBA or the owner of the database to be able to run it.
>
>But i don't want to give the sysdba password to the user, and i can't
>hide it in my application, because each customer database have it's
>own sysdba password.
>
>Is there a way to do the backup with a regular user?
Owner can do a backup.
Follow the good advice and DO NOT deploy databases that were created by
SYSDBA. Always appoint a special user that will have administrative rights
in the database you are going to deploy (for backups, metadata changes,
object privileges, et al.) and log in to your development environment as
this user when creating databases, objects, privileges, and so on.
When you deploy your system, create this special user on the deployment
site. Advise the management of the site to take the usual precautions with
this admin user's login credentials that they would take with
SYSDBA's. SYSDBA of course can vaporise any database; an Owner is
restricted to wrecking only databases that it owns.
Actually, since any user can restore a backup using the -c[reate] switch,
you can change the database owner by recreating from the backup while
logged in as another user. The trap here, of course, is that changing the
owner of the database does not change the ownership of the objects inside
the database. To do the right thing, you will need to rebuild the database
from scratch, i.e. from script, while logged in as the user which you want
to be the owner.
./heLen