INFO: Cannot create workgroup file as normal database

  • Thread starter Thread starter TC
  • Start date Start date
T

TC

We all know that a workgroup file is just a database with certain special
tables and queries.

Some recent questions made me remember an old question of my own, that I
never got around to answering: "If you created a database with the same
tables & queries as a workgroup file, would Jet agree to use it as a
workgroup file?"

The simple answer is, No.

If you try to create certain MSys* table names in a new, blank, unsecured
database, this is allowed. (For example: MSysxyz.) But if you try to create
the critical names, eg. MSysGroups, this is NOT allowed. The error is
something like, "Can not find table or query <whatever>". The error seems
wrong, becauser you are trying to create the table - not read from it. But
if you read the Help proposed for the error, it says that another cause of
that error is, that you are using an illegal name.

So, Jet will let you create *some* MSys names, but not the ones you actually
need! The tables in question do not already exists in the database, so it is
not a matter of "table already exists". There must be special-case code
within DAO, or Jet, to enforce this restriction.

I did these tests from the Access UI. I have not tested it from code, or
using queries to fake the table names, but I imagine the same result occur.

Of course, even if you could do this, and Jet did accept the resultant
database as a workgroup file, it would not be acceptable, anyway. The
objects would not be owned by the system users (Engine etc.), and they would
not have the various system flags & bits set. The only way to secure them
against unauthorized tampering, would be to use user-level security - Catch
22!

TC
 
There must be special-case code within DAO, or Jet, to enforce this
restriction.
*************************************

Wrkgadm.exe is the only program that I'm aware of that will create a mdw
that Jet 35-40 will use. It's possible that this limitation is "by design"
because it requires the purchase of Access or the purchase of an Access
development environment to obtain licensed use of the Wrkgadm.exe program.

The wrkgaadm program creates the sys tables in the JET system file, and JET
is the owner of these objects. Subsequently, any regular JET file will have
SID's based on the system sys tables contained in the particular system JET
file that was in use when the regular JET file was created.

When a user creates a table in a regular JET file, the user is the owner and
the users SID is associated with the table that was created. Attempting to
name the table with one of the special system security table names (e.g.,
MsysAccounts) will fail because these table names are reserved for JET's use
to manage security. Only JET can create them, and JET ownership cannot be
changed..

With regard to messages that JET displays (Access displays either the same
JET error message or a slightly modified version of it) when a user attempts
to use a system object name, these messages appear to be 'by design" too
brief or too uninformative. Most of JET's security error message
descriptions tend not to reveal the true cause of security errors. When
security errors are raised, it usually means that a user is doing something
with JET's security, and JET appears to deliberately avoid revealing at the
moment of occurrence what really caused an error, which adds a subtle but
effective layer of security to JET's security scheme. Of course, programmers
and administrators can replace JET error descriptions with any desired
description, but for secure environments, either less information or a
misleading description is a good first defense from a would be intruder. JET
and Access both appear to take this first defensive measure consistently
throughout their security design. Whether or not this design is intentional,
it's a good model and one that administrators should make use of in secure
environments. Other subtle defensive measures can be realized by asking
questions such as, "Where is JET Located?, Where is the Help File?, Where is
the Wrkgadm.exe file?, Where is the JET system file?, Where is RegEdit"?

To further investigate manipulating JET's security, take a look at the
Container Object, the Documents Collection and the Document Object in DAO.
Jet's security scheme can be managed through DAO using Container and
Document Objects.

If you do anymore research along the lines of that mentioned in your last
post, and if you intend to share the information, please forward me your
results.

Glenn Tarpley
 
Glenn Tarpley said:
There must be special-case code within DAO, or Jet, to enforce this
restriction.
*************************************

Wrkgadm.exe is the only program that I'm aware of that will create a mdw
that Jet 35-40 will use. It's possible that this limitation is "by design"
because it requires the purchase of Access or the purchase of an Access
development environment to obtain licensed use of the Wrkgadm.exe program.
Click to expand...

Maybe. But from a technical viewpoint, *Jet* creates the mdw. Wrkgadm.exe
simply calls the undocumented Jet API which asks Jet to do that. Wrkgadm.exe
would have little if any knowledge of the internal structure of an mdw file.

The wrkgaadm program creates the sys tables in the JET system file, and JET
is the owner of these objects. Subsequently, any regular JET file will have
SID's based on the system sys tables contained in the particular system JET
file that was in use when the regular JET file was created.
Click to expand...

I think this would be more accurate:
o An object, when created, will obtain its owner SID from the MSysUser (or
whatever it is) system table entry for the group or user in question.
o Group & user SIDs are calculated from the user or group Name and PID,
enciphers with DES, then stored in MSysUser (or whatever it is) for future
use as required.
o The admins group SID is calculated by taking the Name, Organization &
Workgroup ID values that are entered when you create the workgroup file,
then encrypting those values with DES. That SID is then stored in the
workgroup file & also in each database file that is created using that
workgroup file. (That's how Jet can tell whether the admins group of the
*current* workgroup file, is the admins group of *the workgroup file that
was used to create the database*.)

When a user creates a table in a regular JET file, the user is the owner and
the users SID is associated with the table that was created. Attempting to
name the table with one of the special system security table names (e.g.,
MsysAccounts) will fail because these table names are reserved for JET's use
to manage security. Only JET can create them, and JET ownership cannot be
changed..
Click to expand...

Well, that's what I just showed! But it is not documented anywhere (AFAIK),
and you can create *other* MSys names, so it is not at all self-evident that
the other MSYs tables could not be created "manually".

With regard to messages that JET displays (Access displays either the same
JET error message or a slightly modified version of it) when a user attempts
to use a system object name, these messages appear to be 'by design" too
brief or too uninformative. Most of JET's security error message
descriptions tend not to reveal the true cause of security errors. When
security errors are raised, it usually means that a user is doing something
with JET's security, and JET appears to deliberately avoid revealing at the
moment of occurrence what really caused an error, which adds a subtle but
effective layer of security to JET's security scheme. Of course, programmers
and administrators can replace JET error descriptions with any desired
description, but for secure environments, either less information or a
misleading description is a good first defense from a would be intruder. JET
and Access both appear to take this first defensive measure consistently
throughout their security design. Whether or not this design is intentional,
it's a good model and one that administrators should make use of in secure
environments. Other subtle defensive measures can be realized by asking
questions such as, "Where is JET Located?, Where is the Help File?, Where is
the Wrkgadm.exe file?, Where is the JET system file?, Where is RegEdit"?

To further investigate manipulating JET's security, take a look at the
Container Object, the Documents Collection and the Document Object in DAO.
Jet's security scheme can be managed through DAO using Container and
Document Objects.

If you do anymore research along the lines of that mentioned in your last
post, and if you intend to share the information, please forward me your
results.
Click to expand...

I only posted this becase someone else has been asking about rewriting the
security wizards. One task that would need to be done, for that, is creating
a new workgroup file. I know that you can do this using the relevant
(undocumented) Jet API. (And also, using other means not to be stated here!)
I just wondered whether you could do it by creating a properly structured
database file. This effort showed that can't be done.

Cheers,
TC
 
Back
Top