Best way to run backup without password in script or commandline

64 views
Skip to first unread message

Nikolaus Kern

unread,
May 4, 2025, 5:41:35 AM5/4/25
to firebird-support
Hello,

I am looking for your experience on the field of backup by using gbak on Windows. I put it into the schedulemanager or use the extra program gbakschedule.

The options of gbak are clear. I am looking for the best way to hide the sysdba pwd.

1. use file with -fetch. pwd is still in cleartext on the server
2. use Windows Credentials manager. Looses the stored passwords after reboot
3. use gbakschedule: Needs also to store the password, last release 2019

Whats your take on this question?

Thanks

Niko

Dimitry Sibiryakov

unread,
May 4, 2025, 5:46:11 AM5/4/25
to firebird...@googlegroups.com
Nikolaus Kern wrote 04.05.2025 11:41:
> The options of gbak are clear. I am looking for the best way to hide the sysdba pwd.

Do not use sysdba for backup. Use database owner or (otherwise unprivileged)
user with backup system privilege.

> Whats your take on this question?

Think wider: if someone got access to backup server - they already got
backups with all your data inside. They don't need password.

--
WBR, SD.

Tomasz Tyrakowski

unread,
May 4, 2025, 7:20:49 AM5/4/25
to firebird...@googlegroups.com
True, but if they _do_ have sysdba password, they can connect back to
the server and make arbitrary modifications in the prod database (which
in general is much worse than simple data theft).

The OP in fact didn't say whether the backup server and the prod server
are two different systems.

If they are, maybe it would be a better idea to run the backup on the
prod server and just copy the .fbk backup to the backup storage.

If they aren't, well, probably it would suffice to block access to the
credentials file the same way you'd block access to the physical
database file. Accessing either of them directly by unathorized users
creates the same danger of fraud / damage / theft.

regards
Tomasz

Tim Crawford

unread,
May 4, 2025, 11:12:43 AM5/4/25
to firebird...@googlegroups.com
I never even thought about creating a user with backup system privilege.
Before I start testing, will it it work if the user has only backup
privs and
most of the database objects are owned by SYSDBA?

( I know I know it's crazy but db is a real mess, dating back to
Interbase days,
and we don't have the resources for rewriting/testing tens of thousands
of lines of code....
a lot of which has SYSDBA user hard coded... etc)

A bit of background, as I have had looked into this same issue:

We run the database on customer owned servers but don't want to give
them access to the database outside
of the application programs so they don't muck things up (cause they
will, and have).

Note for Windows,  if you used a command line parameter, the user and
password is visible
in task manager when you view the command line there.... also not so good.
To get around that I wrote a bat file that runs gbak and set and use
ISC_USER and ISC_PASSWORD

The application programs rettrieve and decrypt the user and password
kept in an ini file
But they are in the script if anyone wants to look for it...
This all really just a deterrent

Ertan Küçükoglu

unread,
May 4, 2025, 11:32:12 AM5/4/25
to firebird...@googlegroups.com
Hello,

It may be a solution if you develop your own backup application. You can use an encrypted password and do not need to store it as plain text anywhere.
There are solutions connecting to the Firebird service and taking a backup. Most likely your choice of database component would support that, too.
Such a database is actually identical to the GBAK database.


Tim Crawford <tim.cra...@gmail.com>, 4 May 2025 Paz, 18:12 tarihinde şunu yazdı:
--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/firebird-support/6bbe9181-9e16-406b-a9ef-2f2eccf01959%40gmail.com.

Ertan Küçükoglu

unread,
May 4, 2025, 11:33:07 AM5/4/25
to firebird...@googlegroups.com
Ertan Küçükoglu <ertan.k...@gmail.com>, 4 May 2025 Paz, 18:31 tarihinde şunu yazdı:
Such a database is actually identical to the GBAK database.
It would read "Such a database backup" 

Dimitry Sibiryakov

unread,
May 4, 2025, 12:06:40 PM5/4/25
to firebird...@googlegroups.com
Tim Crawford wrote 04.05.2025 17:12:
> We run the database on customer owned servers but don't want to give them access
> to the database outside
> of the application programs so they don't muck things up (cause they will, and
> have).

Do you understand that this is technically impossible and the only thing that
can prevent the owner of the server from accessing a Firebird database is their
ignorance?

--
WBR, SD.

Tim Crawford

unread,
May 5, 2025, 10:06:55 AM5/5/25
to firebird...@googlegroups.com
Yup. Just a deterrent.

And side note, as far as I know you can get a cold backup by shutting
down FIrebird
and copying the fdb file? You don't need to use gbak.
Would be good to know if I am wrong on that one
Years ago people here used to just copy the fdb file without even
shutting down firebird.
I told them that is a very bad idea lol.

Dimitry Sibiryakov

unread,
May 5, 2025, 10:11:32 AM5/5/25
to firebird...@googlegroups.com
Tim Crawford wrote 05.05.2025 16:06:
> And side note, as far as I know you can get a cold backup by shutting down FIrebird
> and copying the fdb file? You don't need to use gbak.
> Would be good to know if I am wrong on that one

You are right, cold backup is possible. Even more: it is possible for every
existing DBMS (except may be in-memory ones).

--
WBR, SD.

german...@gmail.com

unread,
May 5, 2025, 3:41:25 PM5/5/25
to firebird...@googlegroups.com
I think the goal is to maintain security. Based on this, one possible solution is to create a user with a backup-only profile.
I hope this idea helps with what you're looking for.


-----Mensaje original-----
De: 'Dimitry Sibiryakov' via firebird-support <firebird...@googlegroups.com>
Enviado el: lunes, 5 de mayo de 2025 11:11
Para: firebird...@googlegroups.com
Asunto: Re: [firebird-support] Best way to run backup without password in script or commandline
--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/firebird-support/b87d011a-cb18-4193-a201-8bc18b0f5080%40ibphoenix.com.

Alexey Kovyazin

unread,
May 5, 2025, 3:54:42 PM5/5/25
to firebird...@googlegroups.com
Hello,

If the final goal is to prevent end users to connect to the database bypassing business applications, the correct solution will be the encryption.

Regards,
Alexey Kovyazin 


Nikolaus Kern <baur...@gmail.com>:
--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

Nikolaus Kern

unread,
May 16, 2025, 2:57:20 AM5/16/25
to firebird-support
Hi,

thanks all for the comments.

My main goal is to hide the password of the backup user. If somebody gets access to server itself, the file can be copied and is then gone.

There is the -FETCH parameter to read the password from a file. Is there a significant benefit to it? In my understanding it does only move the cleartext pwd from the gbak call (e.g. in scheduled tasks) to a file.

Is it possible to map the Windows system - who runs the Firebird service - as user to Firebird and allow this user without explicit password the execution of gbak?

Thanks

Niko

Mark Rotteveel

unread,
May 16, 2025, 3:20:42 AM5/16/25
to firebird...@googlegroups.com
On 16/05/2025 08:57, Nikolaus Kern wrote:
> My main goal is to hide the password of the backup user. If somebody
> gets access to server itself, the file can be copied and is then gone.
>
> There is the -FETCH parameter to read the password from a file. Is there
> a significant benefit to it? In my understanding it does only move the
> cleartext pwd from the gbak call (e.g. in scheduled tasks) to a file.
>
> Is it possible to map the Windows system - who runs the Firebird service
> - as user to Firebird and allow this user without explicit password the
> execution of gbak?

I guess it could be possible with trusted auth, though I'm not sure if
that would also work for local system accounts.

Mark
--
Mark Rotteveel
Reply all
Reply to author
Forward
0 new messages