> The security database customisations outlined by Ivan Prenosil and also by
> Helen are quite clear.
> What's not so clear is that in order to use them at the application layer,
> the application needs to know the full path (from the server's POV) of the
> security database.

Absolutely no. My scripts change only some security aspects,
but they do NOT change the way users are added/modified/deleted.

(the only exception - Firebird 1.5 introduced new bug with handling
computed columns in views, and so it is better to not include Full_Name column
in Users view (or even Users2 table).

Have you also read the other atricle
http://www.volny.cz/iprenosil/interbase/ip_ib_users.htm
?

> When you run GSEC remotely, The server only offers alter/delete/add actions
> to the security database. The threat of public being able to select * from
> users only comes into play when the path of the security database is known.
> 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?

The path to security database can be obtained via Services API.

> Alan
> (Background - I am designing an application which needs to provide SYSDBA a
> simple and convenient (i.e. inside the application itself) way to see all
> users, create new ones, delete old ones and reset their passwords. The BDS
> components for IBO go most of the way but my last stumbling block is how to
> provide the security database path so the application can get a full list of
> the users available.)

To obtain list of users use Services API.
Or connect directly to security database (in which case use Security API to obtain
path to security db).

Ivan