JET Objects & Members Hidden in ACE? Users, Groups, Permissions, etc.

[riktek]

I've been aware for some time that ACE hid a number of objects and members (i.e., properties and methods) that previously had been exposed in JET / DAO 3.6, in the 2003-2007 transition. The Group, Groups, User, and Users objects are hidden altogether, as are properties such as Owner, UserName, Permissions, AllPermissions, PID, and others, and of course, the AddGroup and AddUser methods.

I hadn't paid much attention until now but am curious what to make of these and whether they are still regarded to have utility. They seem handy on the face of things. Still, I haven't managed to come up with anything on the topic, either the reason for their being hidden (are they deprecated or just being made less conspicuous) or on how to make use of them.

I'm curious what the current consensus is on their use, whether they are transparent, ineffective, fraught with pitfalls, or a hidden gem as far as they go. Most security measures individually are speed bumps, after all, but effectiveness improves as they are layered.

Thoughts?

 

[GPGeorge]

I suspect that they were hidden, rather than being removed, because of the risk of bollixing things up internally if they tried to pull them out of the code base.

 

[riktek]

These are all artifacts of Jet and not useful at all in an accdb which uses ACE.

Pat:

Thanks for responding but why is it that they aren't useful, though? Do they not work with ACE or an ACCDB? The properties and objects seem well designed, and close or identical to what I'd think to implement in their absence. Is there a reason not to use them?

ULS was deprecated when Access moved to version A2007

Besides that being a profound step backward, user-level security is precisely what I need to implement. I understand Windows and NTFS are hidebound from implementing it other than perhaps at a folder level but their entire authorization construct is primitive. The ability to accomplish this down to the document level, notwithstanding the incapacities of the filesystem and operating system, is quite appealing, provided the objects can be made to work.

 

[The_Doc_Man]

@riktek

The user and group structures to which you refer have two parts. First, the data structures themselves, and second, the code that would employ those structures. The problem is that while the vestiges of those objects remain in the database object, there is no code remaining in MSACCESS.EXE to attempt to employ that which the structures could achieve.

As a matter of history, they were powered by a library called MDAC - Microsoft Database Access Controls - and that particular feature was a security nightmare. In the interval between 2000 and 2010, the SANS Institute ranked MDAC among the top five security threats to Microsoft non-O/S features. The short answer is that they were trivially easy to identity-spoof, and as such were about as secure as a rusty screen door.

 

[riktek]

I suspect that they were hidden, rather than being removed, because of the risk of bollixing things up internally if they tried to pull them out of the code base.

That's not hard to imagine. 2007 was a heavy lift and a number of things (e.g., abjuring a property to configure Form.Mousewheel behavior for an unconfigurable change in behavior) seem slapdash, driven by product marketing deadlines.

It's also not hard to imagine, e.g., that the Active Directory team couldn't support or keep up with Access / Office in providing user-level security and engineered as much of a feature regression as they could to avoid being shown up. AD is mostly a LDAP wrapper, after all, the latter fully supporting simultaneous user- and group-level security.

Back to reality, this begs the question, though, whether the objects and members don't remain fully capable, and aren't perfectly valid for use.

 

[riktek]

@riktek

The user and group structures to which you refer have two parts. First, the data structures themselves, and second, the code that would employ those structures. The problem is that while the vestiges of those objects remain in the database object, there is no code remaining in MSACCESS.EXE to attempt to employ that which the structures could achieve.

As a matter of history, they were powered by a library called MDAC - Microsoft Database Access Controls - and that particular feature was a security nightmare. In the interval between 2000 and 2010, the SANS Institute ranked MDAC among the top five security threats to Microsoft non-O/S features. The short answer is that they were trivially easy to identity-spoof, and as such were about as secure as a rusty screen door.

@The_Doc_Man , that's interesting, and thanks. You've sparked my curiosity.

I understand you to say (more or less) that the data structures remain but the code referencing them has been disabled or removed.

If you know, what did the msaccess.exe code referencing these data structures do (or might it have done)? Would it have been encryption, or enforcement of the permissions specified in the Permissions or AllPermissions properties, or something else instead or in combination?

 

[riktek]

Why would you want to use objects that have been deprecated? Do you have a death wish? They could simply disappear with your next update. Notice that you haven't had any one say "yes, I use them". They have been deprecated for SEVENTEEN YEARS.

That is (or those are) the questions, of course: Are these deprecated or hidden for security or other reasons? If the former, why (and specifically what is meant in this case by being "deprecated"), if not, are they usable in whole or in part, why or why not, and if so, how?

Seventeen years is a long time for something authentically dangerous to be retained. This begs many questions, several of which I'm posing here. Perhaps the reason these elements remain is simply sloth but if so, I don't imagine after seventeen years that anyone will get around to removing them any time soon. After all, disabling type information for a few classes to prevent their discovery via IntelliSense and commenting a few constructors to prevent their being initialized doesn't make for a big lift over that period of time if an authentic risk exists. This leads the curious to wonder.

Otherwise, a vast and obvious distinction exists between inquiry and advocacy. Nobody is saying they use them but nobody is saying specifically why one shouldn't. I don't know either way but I am curious.

 

[riktek]

So have fun but you are wasting your time

I'm not wasting my time by asking questions. And again, don't mistake rigor for advocacy.

stuff that is easily hacked

The question then becomes, by whom? I'm not looking to fend off the NSA or the GRU. Holding off meddlers and laptop thieves is more the objective. The mathematics of probability tell us that the liklihood of a hack falls with each layer of security. The jury may be out on the utility of these objects and members in particular but regardless, some application-level security is better than none. User-level is better than group level, however implemented. Application-level is better than file-level. File-level is better than directory-level, which is all the filesystem has to offer.

Deprecated means no longer supported.

And yet, they remain. As do WizHook, Application.SaveAsText, and /decompile. This is the general definition of deprecated. Apart from MDAC, no specific reason for these objects and members' persistence has surfaced. We all know the risks of use, obviously, but each of these elements has a reason for its existence, even if in the limbo of a hidden state. The question is what that reason is. Perhaps they're just handy data structures for custom code. Perhaps there is more. Many of the properties and objects continue to be referenced in the 365 documentation for the Container and Document objects, which doubtless is purposeful.

 

[sonic8]

I suspect that they were hidden, rather than being removed, because of the risk of bollixing things up internally if they tried to pull them out of the code base.

There are two reasons for hiding them instead of removing them.
1. Removing them would break backwards compatibility of the DAO object library with previous versions. This is would be a huge problem for older application using DAO, even if they don't use the permission system at all.
2. DAO still fully supports the old permission system. But only for the MDB file format!

 

[DickyP]

Interesting concept 'deprecated'. I know what it purports to represent but experience of the IT industry shows that it actually represents many things.

The supplier, in most cases Microsoft, wants to get rid of a feature but can't because it is intimately embedded in their own soft ware.

The maintainer has retired and nobody can maintain it although it works perfectly. We'll keep it as long as we can.

It is too difficult to bring into line with other totally unnecessary changes being introduced (that there is no apparent call for.). We'll keep it as long as we can.

Just dumping a feature is simpler than updating it, however well used it is. But users are complaining

Cynic - me?

 

[sonic8]

Personally, I would have prefered that they fixed the issues but no one asked me.

The issue with every file based desktop database, not just Jet/ACE, is that the code providing the "security" is running under the control of the potential attacker, who also must have unrestricted file level access to the database.
This issue is unfixable!
So, instead of continuing to keep up this illusion of security, the Microsoft Access team decided to drop it altogether. - This was a sensible choice in my humble opinion.

 

[The_Doc_Man]

If you know, what did the msaccess.exe code referencing these data structures do (or might it have done)?

It was more "permissions" oriented than anything else. You could attach permissions (Access Control Lists in the more modern vernacular) to various objects like tables, queries, forms, and reports. You could define groups of users and give permissions to the group as well as to individuals. You could make something READ-ONLY or R/W or various other options. It has been nearly 20 years since I played with it, so I don't recall all of the options. The database encryption option was NOT part of ULS/MDAC.

The danger of Access ULS features was that the protection was an illusion that wouldn't stop a dedicated and persistent hacker. It was security that was inherently insecure and thus highly dangerous for people actually NEEDING security - dangerous by offering something it couldn't really offer. Dangerous by giving people a false sense of security that might lead to failure to check for changes and interference in what you were doing.

 

[GPGeorge]

There are two reasons for hiding them instead of removing them.
1. Removing them would break backwards compatibility of the DAO object library with previous versions. This is would be a huge problem for older application using DAO, even if they don't use the permission system at all.
2. DAO still fully supports the old permission system. But only for the MDB file format!

Much clearer explanation than "bollixing things up".

 

[riktek]

The issue with every file based desktop database, not just Jet/ACE, is that the code providing the "security" is running under the control of the potential attacker, who also must have unrestricted file level access to the database.
This issue is unfixable!
So, instead of continuing to keep up this illusion of security, the Microsoft Access team decided to drop it altogether. - This was a sensible choice in my humble opinion.

Not necessarily.

The NTFS / Windows authorization construct indeed is incapable of establishing user or group permissions for files. The best it can manage is to enforce them at the directory ("folder") level. So, a hacker with file access has full access to the code.

Still, if objects natively implement user and group security, then no amount of file or code access will permit a hacker to do anything with those objects without spoofing the credentials of the object's user and group owners.

I have no idea if ownership and permisisons were implemented this way in Access / JET but this is the essence of the authorization model for EXT4 and the Linux filesystem. Yes, with root access, one can change mode and ownership at will but that requires physical access to the machine, operating system, and media. Here, were authorization to be implemented at the object level, one wouldn't be able to gain such root access without credentials.

 

[The_Doc_Man]

The NTFS / Windows authorization construct indeed is incapable of establishing user or group permissions for files.

I have to vehemently dispute that statement unless you were couching your comment in an obscure manner or were perhaps having an unusual take on the word "establishing."

An individual file can have a security structure called an Access Control List or ACL that equally handles groups and individuals. The ACL might not be the most elegant structure ever created but it definitely can be - and has been used in my presence - to declare individual rights on files in a domain environment. The U.S. Navy used it all the time. When I got my CompTIA Security+ certificate, ACL design was an issue that we studied.

The kind of ACL that allows a user to have (or not have) access to a file is called a Discretionary ACL and involves up to 22 different specific permissions depending on the file type. You can also have the broad-brush permissions (that are essentially "bundled" permissions) such as READ, WRITE, MODIFY, FULL-CONTROL, all of which imply specific permissions. When you apply permissions to a folder, that can restrict the creation of files, deletion of files, etc. When you apply DACLs to files, you can protect or expose single files.

 

[gemma-the-husky]

I haven't read the whole thread, but I wouldn't be surprised if you could still manage these values with DAO objects.

I thought the issue was that all users are granted admin rights in later versions of access so anything that examines membership of other groups will not work.

Within a database it's relatively easy to construct a series of tables to mange groups, users and permissions. The real issue is that managing it other than at form level is going to be incredibly hard. As was ULS.

Try to come up with a way to enable some clerks who are able to use customer accounts, be prohibited from changing the credit limits. It's extremely difficult to manage form behaviour other than at at atomic level of the forms themselves. So have one form that manages customers, and a separate form that manages credit limits, rather than find a way to permit/allow the credit limits to be changed within a single form, depending on the user.

Building a system that grants privileges to individual fields at a user and/or group level must be incredibly difficult to do and manage, given the thousands of fields you are likely to have. I wonder how many people got locked out of their own databases by losing the password to their security object. (I forget the exact title). It's hard enough to manage and maintain access to forms and reports, never mind fields.