Helen,

Thanks for your good advices. I was running everything as root, and
that was wrong. But while trying to do the things the right way I have
the following questions:

1) If the right way to run gbak is using -se option in order to invoke
the service, which is the usefulness of not using it (i.e. why this is
an option or when it is convenient to not use it ? )

2) I noticed that you advised me to create databases as an ordinary
firebird user instead of using sysdba (gbak -c -user dbadmin ..). Is
there any harm or risk in making a sysdba owner of a database (gbak -c
user sydba ... ) ?

3) The only way I found of running the other tools ( isql-fb, gfix and
gsec ) as a non root linux user was appending localhost: before the
path to the database file or its alias, which indeed serves to invoke
the loop back connection to the server instead of using a direct
connection. Is that right ?

Thanks again,
Aldo

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 03:45 AM 3/04/2007, you wrote:
> >Hi,
> > I'm running classic server on Debian.
> > When I restore a database ( gbak -c ), the restored file belongs to
> >root. I can connect locally ( isql-fb ), but if I connect remotely I
> >receive a permission denied error code.
>
> When you connect locally, you are connecting directly to the database
> file and your process is running in the logged-in user's application
> space. From your description it appears you were logged-in as root
> when you ran gbak. The root user has the same Firebird user powers
> as SYSDBA on POSIX systems.
>
> Running applications as root is not something you should ever do for
> any applications, Firebird and its tools included. Ideally, for
> backups and restores, you should use a local loopback connection and
> the -se[rvice] switch and provide a proper set of Firebird server
> login credentials.
>
> If you want to do admin stuff via the direct connection then create a
> system user that is going to be your database owner/admin, let's say
> you name it 'DBADMIN'. That user should be the only one that creates
> databases and runs backups and restores. Create a firebird group if
> it does not already exist and add DBADMIN to that group.
>
> In your security database, as SYSDBA, create an authentication record
> for 'dbadmin'. (Firebird will store it as DBADMIN). Include the
> system user name ('DBADMIN') and group (firebird) in the
> record. Then make sure that you are logged in as this user whenever
> you use the direct connection method.
>
> However, the proper way to have done this restore would have been as
> follows (assume we are located at /opt/firebird/bin or wherever
> Debian locates the firebird binaries):
>
> ./gbak -c -user dbadmin -pas wxyz8765 -se localhost:service_mgr
> /data/bkp/mybackup.fbk /data/mydb.fdb
>
> > The only way I found to avoid it is to change manually the *.fdb
> >ownership to firebird:firebird and REBOOT the sever (?)
> > I tried starting and stoping inetd server, killing fb_ processes,
> >but still I can't connect manally.
>
> When you use the direct connect method, inetd is not involved. I
> notice you talk about "killing fb_ processes" as a plural. There
> should have been only one; and, if the restore had finished
> normally, there would not have been any, i.e. there should be no
> processes to kill.
>
> If there was still a fb_inet_server process running then it is
> probable that the restore had not finished. If there were multiple
> processes then you had some kind of a minefield there.
>
> > So my questions are:
> >Why does gbak create files belonging to root instead of firebird user ?
>
> See above. Don't connect to databases as root and don't run gbak as
root.
>
> >Why should I have to reboot in order to make take efect and ownership
> >change ?
>
> If the database file was open at the time you did the chown then the
> changes would be deferred until the file was properly closed. If you
> saw fb_inet_server processes running then the file was definitely not
> closed. Note that disconnecting from the database is the only way to
> end a fb_inet_server process normally.
>
> However, if you do things the right way, there won't ever be a need
> to alter the ownership of any database file.
>
> Keep the root user right out of the picture. It doesn't belong in
> this environment at all. And, if you are planning to do admin stuff
> via a direct connection, instead of via [x]inetd, then make sure you
> get your user environment properly set up FIRST.
>
> ./heLen
>