Hello Paul

Thank you very much for replies. I really appreciate
it.

--- Paul Vinkenoog <paul@...> wrote:

> Hello Pri,
>
> > In my case, filesystem level permission is not
> applicable.
>
> Do you mean that it will (also) be installed on
> filesystems that don't
> have access protection (like FAT) ?

Yes :(

> If so, anybody with access to the filesystem can
> grab the database,
> take it home and examine it. You can encrypt the
> data, but since
> that's done by an application on the same computer
> (if you use
> Embedded), malicious users could also copy the
> application and
> decompile it.

Yeah. IMHO, Encrypting the data also make me harder
deal with report generator (since report generator i
use read directly from dataset dan display it; i have
no chance to decrypt it before display).

>
> Metadata can't be encrypted, except that you can
> delete the PSQL
> source of your stored procedures and triggers (not
> that it will help
> you a lot - see the meta security article that Adam
> referred you to).

Thanks. I already read that manual and it help me a
lot. I think, actually, we wont have many stored
procedure and/or triggers.

>
> Also ask yourself - if you encrypt the data on an
> unprotected
> filesystem, how are you going to protect the key?
> It's very very hard
> to protect anything if you work on a filesystem
> where you can't shield
> data from unauthorized access.
>

Hehehe. Yes. It would be very hard. I think the key
would be entered by user?

> If the database must be accessed from other
> computers than the one it
> lives on, you can't use Embedded. The database must
> always be on the
> same computer (physically! no network paths) as the
> server, whether
> it's an embedded or a regular server.

Hmm. Seems as bad news to me :( I am stupid thinking
of sharing database file using SMB or NFS. Thanks a
lot for this information. I am little confused, why MS
Access database doesnt have this problem? MS Access
Database must be more simpler than FB.

> Another consideration is that an embedded server
> places an exclusive
> lock on the database, so you can't have simultaneous
> connections.
>
> I think you could solve at least part of your
> problems by opting for a
> regular client-server model after all. With a
> regular Firebird server:
>
> - You can place the server and the database on a
> computer that only a
> few trusted people (administrators) have access
> to; or at least on a
> protected filesystem, in a tree only accessible by
> those few.
> You can even place them on an encrypted
> filesystem.
>
> - You can decide who gets access to the database at
> all, and you can
> manage access rights to any objects inside the
> database. "Access"
> meaning here that users can query the server for
> data, *not* that
> they can get to the file itself.
>
> - Users can connect from across the network, but
> they must provide a
> valid username with the right password. Once
> authenticated, they
> only have access to the parts you want them to
> have access to, and
> they have the type of access that you determined
> (e.g. read-only,
> read-write, execute, etc.)
>
> - Several users can connect simultaneously.
>

Thanks for this information:) I will read it again
very carefully, and will try to make it as simple as
possible. Thanks again.

> You can protect your data and database structure
> even more by
> introducing a middle layer: clients connect to the
> middleware, and the
> middleware connects to the Firebird server. This
> Firebird server could
> even be an embedded server (not that this would be
> my choice) provided
> that it and the database are hosted on a
> computer/filesystem that your
> ordinary users have no access to.

In my case, is this might mean that i have to write
server version of my application? It would be hard to
provide security, networking stuff and et cetera.

> Installing a regular Firebird server is a bit more
> work than packing
> Embedded with your application, but not that much.
> It's a pretty
> simple and straightforward process, and you can make
> it part of the
> installation procedure of your application.

Yes. Very agree with this.

>
> If you *really* won't do that, you must accept the
> low or totally
> absent security that's inherent with users having
> access to the
> database file itself.
>
> Or, look at it this way: why go out of your way to
> think up all kinds
> of protection/encryption schemes for an inherently
> insecure access
> model, if you can achieve the same level of
> protection by using a
> proper client/server setup, which is certainly less
> work?
>

Yes. Thank you very much. I think i must go with
client/server model.

Thank you very much Paul.

Pri

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com