At 02:37 PM 28/01/2005 +1100, you wrote:

> > Well, it's only correct if the tool is located in the application
> > directory.
>
>the tool doesn't have to be in the application directory. I use IBExpert
>with the embedded server as the client library. I can therefore connect to
>any database sitting anywhere locally without a local server running) AND
>remotely to a server.

This seems to suggest that you are running fbembed.dll (as gds32.dll,
presumably) in the system path. (I saw you advising someone yesterday to do
this...) Isn't this asking for trouble?

> > It's not true if the database is installed on a
> > machine that is
> > running the Firebird "full" server
>
>but Peter is referring to an embedded server app with an adjacent database.

And so am I.

> > and Database Workbench (or some other
> > tool) is installed out of reach of the embedded server library. The full
> > server always requires a user name and password.
> >
> > It's also not true that the FDB that you ship has "no security
> > whatsoever",
>
>in the context of the database file floating around for any tom, dick or
>harry to poke around inside it with any tool they fancy, I'm afraid "no
>secuity whatsoever" is a more accurate description of reality.
>If someone were wanting to look into the file, they wouldn't be thwarted by
>a failed login via your application.

The security warnings are all there re embedded, considering that it can
run in any system user's application space. We can't prevent someone
inserting a tool that can use the embedded server and we'll certainly make
it easier for them if we make access to fbembed.dll wide open. Heck, why
not just share the application tree with the whole LAN and just let them
filecopy the lot?

> > unless you ship your FDB with no SQL privileges defined. Define
> > privileges
> > for a specific user name and/or role -- that is a variable in the
> > application -- and pass this as part of the connection string. You can
> > have the user "log in" using this username as her "password" and
> > block any
> > other username, including sysdba, from getting past your login
> > prompt. Then, at least as far as the application is concerned, you lock
> > out rogue users.
> >
> > (But it won't stop anyone who installs DB Wb or isql or whatever into the
> > app directory, since they can use sysdba in their login and get access to
> > everything. So write it into the contract that you won't take
> > responsibility for security breaches resulting from user misbehaviour or
> > sloppy site security).
> >
> > ./heLen
>
>I don't know what you mean about it having to be installed in the
>application directory. I have no such impediment to using the embedded
>server on any file on my disk.

Your example was Database Workbench. If you install DBW (or isql or
IBExpert or whatever) on a machine that doesn't have a full server
installed, then DBW needs to find a client and then the client needs to
find a server. If it finds fbembed.dll (renamed to a libname DBW
recognises, such as gds32.dll or fbclient.dll) then it has found both in a
single hit, and the door is wide open. You're telling people to put the
(renamed) fbembed.dll into the system directory. You're the author of your
own misfortune if you decide to do that, or if you modify the system path
so that the location of the library is added to it. You're simply
announcing "Come and get me!"

Sure, it's all-same-different if someone steals the machine or milks the
disk. Security is as security does.

./heLen