At 12:37 PM 14/12/2004 +1100, you wrote:

> > At 12/13/2004 07:17 PM (Monday), Alan McDonald wrote:
> > >So how does a hacker or even someone who has genuine reason to know, find
> > >the path to the security database without asking that the
> > sofware installer
> > >find the path and register it with the application?

Gosh, you don't need an API call to find out where the security database
is. It can't be anywhere other than where it always is, in the server's
root directory. Not only is it widely and public documented, it's obvious
to anyone who installs the server. So expecting to secure the security
database by obscuring its location is a non-issue.

Doug Chamberlin wrote

> >
> > I wrote a UDF which provides the full path of the security DB to
> > the user.
> > That way I can make the client application independent of the server's
> > configuration. Not the most secure thing to do but it does avoid
> > some problems.

In Fb 1.5 a user application doesn't need to know the path to the security
database, or any database. Whether you invoke a command-line utility from
a remote client, or use the Services API, you can use an alias. The
application never needs to know where to find the security database, never
needs to store or read paths at all. Everything can be compiled with
aliases in lieu of paths. For deployment, it's totally server-specific and
site-specific.

For Fb 1 and InterBase, it's a bit more of a challenge, esp. if you don't
know from whom you're meant to be hiding the paths. On Windows clients,
you can store the path in the client's registry or in a .conf file in the
user's Docs and Settings area; on Linux, a .conf file in the user's /home
directory would be equivalent. Either way, though, you can't avoid passing
the hard path over the wire, there's no need to hard-code it in the app.

./heLen