Note:
All references are to DB's set to Database security model.


I've tried several different methods. Start FE and select login;
neither Master or any other user can login. Response is something like
"Wrong user name supplied." I thought this might be the WinXP Pro
policy for authentication as stated in "Security Issues", but same
results on Win2000 client.

Wait, there's more. If you login at the OS level as a domain user, you
have full rights to table data. You are not prompted
for a database login and even though you are not a defined user of
that database, you can update, insert or delete to your heart's
content. Who know's what the difference between alter and modify is?

Wait, there's more. And this is not insignificant. If you want to add
an existing Btrieve file into the new database security scheme, forget
about it. First, you CANNOT create a new database and then expect to
proceed with key and field definitions. It MUST be included in
DefaultDB. Second, if your Btrieve file structure uses a field in more
than one key definition, it CANNOT be defined in that database.

So, instead of adding a security layer on top of the BTRIEVE API, it
appears you will have to re-structure every Btrieve file you have ever
used and one other thing. You will have to rewrite every application
(i.e massive code changes involving thousands of hours)you have ever
written to take advantage of the new database security model.

I haven't tested what constraints are imposed if you wish to use wire
encryption.

Jim:

I believe that these are common misconceptions before one takes the time
to pour through the manuals -- I myself had a lot of the same comments
about the new V8.5 stuff.

In short, you you correct in that if you create a database with DB
security and throw an old-fashioned Btrieve application at it, it does NOT
leverage the new security stuff! This is actually clearly stated in the
manual, though perhaps not in the "marketing stuff".

Like many other new features of the Pervasive database, the backwards
compatibility requirements always weigh in on how easy and/or difficult it
will be to accomplish change. Pervasive in unable to provide wide
sweeping changes without breaking every application, so they add new
features and allow developers to take advantage of them if they wish.
(This is the same thing as the new "Smart Components" requesters -- if you
still compile your application for WBTRV32.DLL, it will work, but you
don't get the "new version guarantee" as you would if you changed your app
to use W3BTRV7.DLL instead.)

Here is the way the security should be viewed:
1) If you leave security off and do nothing to your apps, you have
OS-level security, just like every other version of the database. All
programs work the same; all security is the same (OS-level).

2) If you change your application to use the new database-level login
functionality, AND you enable Database-level security, then you can
exploit the new database-level security functionality. However, you MUST
either call the Btrieve Login function at the start of the app (a very
simple thing to change for most developers) OR you must change the
programs to use URI's for locating files (may be more complicated, may be
easier, depending on the app).

3) If you want database security, but you cannot change the application,
then you still have an option to use the new security model -- you can
enable security on the DefaultDB database. This database takes over for
ANY database access that does NOT use the Login API call. (Note that a
NEW application with the Login call will go to the correct database --
anything without a Login call goes to DefaultDB.)

It is this last feature that gets the most confusing. People think (just
like I did the first time I started messing with it, over a year ago in
beta trials) that if they define a database, then define user rights, then
use their same old database applications, that the system will work with
the new rights. However, without the Login database call, there is no way
for the database engine to know to which database a given file belongs.

For example, what if I create a file C:\DATA\DATAFILE.BTR. Not, I create
a new database called MyData, located in C:\MYDATA that points to files in
both C:\MYDATA and C:\DATA. I then create a new database called YOURDATA
that accesses files in both C:\YOURDATA and C:\DATA. Whenever we open a
file in the C:\DATA directory, how should the engine know which rights to
use, or which database to authenticate even? Additionally, if you have a
server with 10 databases, then EVERY time you open a file, the database
engine would need to open and check the rights on all 10 databases just to
decide who should be the controlling DBName for this instance -- it would
make FileOpen calls take 100's of times longer!

Recommendation: Spend some quality time reading through the manual
sections on security. They are not a very easy read, and can get
confusing at times. (It took me two passes through it, then two attempts
at explaining it to other people before the "Aha" moment hit me.) Then,
sit down with the engine and work through it one step at a time, building
various test cases. I think, when all is done, that it will make a bit
more sense to you.

BTW, as for the wire encryption issue, you MUST have V8.5 or higher on
BOTH sides, and the encryption settings must be "compatible". This means
that you can't have the server set to ALWAYS and the client set to NEVER,
or vice versa. Leaving the server set to IF NEEDED, you can then control
the encryption from the client's perspective, so that in-house computers
can run with encryption disabled, and "public" systems on the Internet can
run with encryption enabled.

Two more things: If you enable encryption, expect a 20 percent performance
degradation to occur on that connection, so you should only use it if you
need it and security is more important than performance. Also, if you use
it, you may as well enable the "High" encryption. Apparently, a
fixed-length encryption algorithm of the type used (i.e. Blowfish) always
takes the SAME amount of time, regardless of the key length. Thus, the
"Low" 56-bit encryption suffers from the same 20% overhead as the "High"
128-bit encryption.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: August, 2004: See our web site for details!


Jim Buttery wrote:

Bill:
All functions are OK in PCC. Attempting to use function executor with
no OS rights gives "Wrong name", status 94, etc.

btrv://myserver/demodata?dbfile=class.mkd


Bill Bach <bbach (AT) cncdsl (DOT) com> wrote