Update Secured MDB, No MDW Distributed

[Tom G]

IF a person uses the logic of the Microsoft Access security FAQ and
distributes an application WITHOUT the developers MDW file, but simply uses
the default workgroup file, how does one modify the user's 'DATA' database?

Any changes to code would simply require re-distributing the MDE, but each
user has data in the back-end database already, so how do you make updates
without losing that data?

I've done 'data' database updates through code many times, but I've always
had the MDW at my disposal for creating a workspace, but what if that MDW
wasn't there?

I can see some possible solutions:

1) Travel to each client site with the MDW and make the modifications.
2) Have each client email or upload to a server their data file, update the
file, re-send to the client
3) Try to hide the MDW file with some innocuous name? Code the update
either in the front-end or a separate 'update' mde program.

ANY ideas or thoughts on this are greatly appreciated! Thanks in advance!

 

[Joan Wild]

IF a person uses the logic of the Microsoft Access security FAQ and
distributes an application WITHOUT the developers MDW file, but simply
uses
the default workgroup file, how does one modify the user's 'DATA'
database?

It is rare that I have changes to a backend database, but if I do I
generally do it via 2.

 

[TC]

If you had to, you could provide a second MDW with a nonstandard name;
eg. AppStat.DLL (!) Then, your code could open a workspace for an
administrative user in that file. Not much chance that any users would
try joining AppStat.DLL, or running username/password tools against it!

You could even arrange to create the second MDW at runtime, in the temp
directory, and delete it afterwards! Perhaps include it as a resource
in your EXE, or as a binary blob in your data db, or whatever.

HTH,
TC

 

[Tom G]

Thanks for the replay. Yes, this should be rare.

Anyway, I'm not sure anymore why I'm so uptight about the mdw when all
anyone has to do is download any of a number of available programs and get
my DB owner and PID, and simply create their own MDW with that info, and
wham, the data is all theirs..... Right?

Curious, I got this to work but questioning my logic...

1) I opened the actual MDW file (actually a copy of course...)
2) I added a form and code module within the form to do my database updates
(using PrivDbEngine and referencing itself as the MDW, Currentdb.Name)
3) I compiled the file to an MDE, no more looking at code...
4) Open this new MDE file, using default workgroup, run the code and the db
updates are performed

By distributing this, I'm really not giving my users any more info than they
can get right now (by buying certain programs...) and they probably wouldn't
guess that this is actually an mdw in the first place (AGAIN, not that they
need the mdw...)

Any thoughts?

 

[Tom G]

If you had to, you could provide a second MDW with a nonstandard name;

eg. AppStat.DLL (!) Then, your code could open a workspace for an
administrative user in that file. Not much chance that any users would
try joining AppStat.DLL, or running username/password tools against it!

Yes, that would be my option #3...

You could even arrange to create the second MDW at runtime, in the temp
directory, and delete it afterwards! Perhaps include it as a resource
in your EXE, or as a binary blob in your data db, or whatever.

Now THAT is an interesting thought.... Can I create an MDW just from code?
I know I've never tried but will check that out.

Also, as I indicated to another reply I received.... This may all be a bit
beside the point as a user could obtain software to get my DB owner and PID
and simply create their own MDW... And then they are in my database....
Right?

Thanks for the reply and the idea....

 

[TC]

Tom G wrote:

(snip)

Anyway, I'm not sure anymore why I'm so uptight about the mdw when all
anyone has to do is download any of a number of available programs and get
my DB owner and PID, and simply create their own MDW with that info, and
wham, the data is all theirs..... Right?

With one proviso. It is commonly but wrongly believed, that the db
owner always has (or can acquire) full access to all the objects in the
database. That is not correct. You can easily create a database in
which the db owner does not have access to some objects in that
database.

Normally, the db owner also /owns/ the objects /in/ the database. That
is why he has full access. But you can easily have a db where the db
owner does not own the objects (and does not have full access to them).

So, in your scenario, the user really needs the Admins group PID (and
workgroup level details: company name etc.) - not the db owner details.

Cheers,
TC
(off for the day)

 

[Tom G]

OK... so do I change the owner of the database or the owner of the objects?
Is this documented in a different NG thread, I looked but didn't find...

Also, changing ownership of the DB itself, does that require creating a
user, logging in as that user, importing all the objects, then
verifying/resetting permissions on the objects? And in doing so, doesn't
that make the new user the owner of all those objects????

 

[TC]

(snip)

Now THAT is an interesting thought.... Can I create an MDW just from code?
I know I've never tried but will check that out.

Yes, there are various ways you can do that. For example: create the
MDW on your own PC, then use VBA to open it as a binary file, and read
it's content into a suitable field of a record in a table in the db.
Then, at runtime of the db, VBA code could retrive that content from
that field, and write it out as a binary file: thereby "creating the
MDW at runtime".

Also, as I indicated to another reply I received.... This may all be a bit
beside the point as a user could obtain software to get my DB owner and PID
and simply create their own MDW... And then they are in my database....
Right?

As I said to your other post, the db owner PID is not always enough.
However, on reflection, that point is probably a bit academic to what
you are actually asking. The real point is, that using the software in
question, an evil user can recreate any user or group in a workgroup
file. So, he can recreate the Admins group. Then, if that workgroup
file is the one which you used to create the database initially, then,
the recreated Admins group will let the evil user take over your db.

Cheers,
TC