--- In firebird-support@yahoogroups.com, "Peter Turner"
<PeterTurner@...> wrote:

>

Hello Peter,

> The downside to using a script is that you have to pass the

parameters (username and password), at least in my case, as clear
text. This creates a potential security problem.

Many of these third party tools store the passwords in a plain text
ini file or registry setting.

If you are using a modern or server version of Windows, this is not a
problem. You are able to encrypt the bat file, or set the user
permissions on the file to only allow read from the account you set
the scheduled task to run as if it is running on trusted hardware.

>In addition, to run the job as a scheduled task, you have to specify

a user. You can use the built-in SYSTEM account. Another thing is
that the firebird server needs to be running.

>

It is good practice to set up a different user account for the
Firebird and associated processes. This way you can use the OS to
limit the impacts of any security flaws found in Firebird, and you can
prevent users from having access to the database outside that provided
through the service.

>
>
> I'm mentioning this, as we had a similar situation. We're running

FB 1.5.3 and needed to run an unattended backup. Our configuration
was such that the firebird server couldn't be run as a service - we
support platforms from 98 thru Vista and 98 doesn't support services.
We wanted to have only 1 configuration for our application
environment, so we chose the least common denominator and went from
there. Bottom line, we ended up writing an application that is a
scheduled task, which was run using the SYSTEM account. This
scheduled task checked for the firebird server, and if it wasn't
running, it started it, ran the backup (gbak), and stopped the service.



Your situation is quite unusual, and certainly not ideal. You should
be making use of services where available and offer a compatibility
mode for 98/ME rather than cripple 2K,XP,2003 & Vista, all of which
can make use of the service.

Another concern is that you kill the fbserver upon completion. What
happens to some other client if it happens to connect why gbak is
running? One can only hope that this is run at a time of the night
when it is impossible for that occasion to happen.



Internally, the application simply calls CreateProcess, but with
appropriate parameters, the parameters to gbak aren't exposed. Looked
into some of the other packages mentioned in other posts, and decided
that we'd stick with the native gbak utility.

>

Here is the complete source to a Delphi app that will sniff the password:

program gbak;

{$APPTYPE CONSOLE}

uses
SysUtils,
System,
Dialogs;

begin
ShowMessage(cmdLine);
end.

Compile and overwrite the one in your Firebird folder, and you get the
entire gbak string as issued by the calling application in plain text.

If you are going to the effort of writing an application, you may as
well just run the backup through the services API.

I do not mean to rain on your suggestion. It may be 'secure enough'
for your solution, but it is actually impossible to lock down your
database under 9x. FAT32 simply does not have the required user
account features.

Of course, the user could simple take a file copy of the database
rather than try to steal your password, and you do not have the
possibility of preventing it.

For the record, I have also written a backup application. We have many
databases on the same server, so my program parses aliases.conf for
the databases of interest (based on a base folder) and backs them up
sequentially (to manage load), then does a test restore of each. A
batch file then compresses the file (7zip) to be sent offsite, so I am
definately not saying it is not a good idea to write your own app
where no pre-written apps are appropriate.

I also have another backup / restore application that is simply a
wrapper around gbak for internal use (the password is stored in plain
text). There is a file association set up, so I can right click on a
fdb file and choose backup; or right click on a fbk file and choose
restore.

Adam