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

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