JET Objects & Members Hidden in ACE? Users, Groups, Permissions, etc. (1 Viewer)

[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?

 

[Pat Hartman]

ULS was deprecated when Access moved to version A2007 which meant that it was using ACE rather than Jet. These are all artifacts of Jet and not useful at all in an accdb which uses ACE.

 

[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.

 

[Pat Hartman]

Do they not work with ACE or an ACCDB?

No. you cannot use the security with an .accdb

 

[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.

 

[Pat Hartman]

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.

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.

 

[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.

 

[Pat Hartman]

Deprecated means no longer supported. If you see deprecated artifacts in the interface use them at your peril. Sometimes, MS chooses to not excise every single reference or object because they don't have time/can't be bothered to track down potential off-label uses. So, they leave the objects. Please tell my you've never ever done that yourself.

I'm not the one who said they were dangerous. Doc said that MDAC was dangerous. Not in and of itself, but it was too easily cracked by hackers. So, if you want to use stuff that is easily hacked, have at it.

Wonder all you want. I'm telling you that if MS says something is deprecated, you may be able to use it today but not tomorrow. No warning - just gone. So have fun but you are wasting your time. You have been warned. And I say this as someone who has been burned by this particular MS policy. I once created a bunch of utilities for my self using the MSys tables. But, like many undocumented things. MS can and does change its own objects at will and without notice. Poof, they're gone.

 

[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!

 

[Pat Hartman]

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

I never said that asking questions was a waste of time. I said USING deprecated items was a waste of time.

And yet, they remain.

I told you why and now Sonic8 has told you again.

 

[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?

 

[Pat Hartman]

ULS had a lot of problems. The biggest of which was that most people simply didn't understand how it worked and frequently ended up not securing the database they were interested in securing. Anyway, when MS took Jet and turned it into ACE so they could control their own destiny rather than relying on the SQL Server team, they elected to not include ULS due to the fragility of MDAC and the frequent misunderstanding of its actual use. So, it still works for Jet but not for ACE. It is as simple as that.

Personally, I would have prefered that they fixed the issues but no one asked 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.

 

[Pat Hartman]

This issue is unfixable!

Clearly I should have clarified. I agree you can't protect the data with ULS but it made it far easier to distribute applications that the user couldn't crack.

Since I rarely use Jet/ACE BE's I forget that when I say Access, I mean the FE but you all are "hearing" BE and not even considering that I might be thinking about the FE only. Let me clarify for you for future reference -- I ALWAYS say Jet/ACE when I'm talking about the desktop database engine just in case you've never noticed. So, when I say "Access", I am probably talking about the FE.

MS needed to provide something that went beyond the .accde to protect development objects.

 

[Pat Hartman]

So, instead of continuing to keep up this illusion of security, the Microsoft Access team decided to drop it altogether.

The MS team considers an Access database to be a "document" just as we consider a spreadsheet to be a "document". They do not look at an Access database as an application but we do. Therein lies the differences in our point of view. WE, the Access developers of the world, look at Access as a software development platform but MS does not consider what we create to be applications. They look at the product of our work as "documents". Quite a different point of view and explains why MS' focus is always on office workers rather than thinking about providing useful features for developers.

 

[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.