Permissions with DAO

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

TC

I worked on this some time ago. Unless you have a very special need, it
simply is not worth the effort. You can set, reset, or test the current
setting of any of the security constants, using appropriate simple tests. If
a particular constant happens to comrpise more than 1 bit, that has no
affect on the code for those tests. If you start changing the bits
individually, you are walking on fire, unless those bits correspond exactly
with one of the predefined constants - in which case, you might as well be
using the constant! The individual bits are completely undocumented, & there
is no saying what will happen when you set them individually, in undefined
ways.

HTH,
TC
 
I'm exploring the use of DAO to examine and set Access permissions. This
involves using intrinsic constants that define bits in a 20-bit mask. This
mask is referred to in Article 37 of the Access Security FAQ. A reference in
that article leads to a table that defines each of these constants. After
getting the decimal value of each constant and converting that value to
binary, I see that some of the constants represent an individual bit but
other constants represent a combination of bits. Some of the 20 bits aren't
used at all.

I've looked for a detailed explanation of the 20-bit mask, specifically what
each individual bit represents, but haven't been able to find it. If anyone
has this information, I'd appreciate receiving a copy. Thanks.

Gordon
 
Gordon,

Most likely the bit definitions to which you refer are not well defined. The
security constants are enumerated constants. Enumerators provide an easy way
to define a group of long data types (4-bytes) as constants. DAO has the
PermissionEnum enumerator that you can view from an object browser. What
follows is one example of how this enumerator might be defined at a source
code level (using VB semantics and syntax).

Public Enum PermissionEnum

dbSecNoAccess = 0
dbSecDBOpen = 2
'...
'...Other Constants
'...
dbSecDBExclusive = 4

End Enum


When an application is distributed that uses enumerators, it is generally
expected that code using the enum's will use the enum identifiers, not the
assigned values because these values might change in future releases of an
application that defines the enum. For example, in practice one should use
the identifier dbSecNoAccess rather than hard code its value, zero. This
strategy permits an apps enumerator values to be changed without breaking
existing code. For example, dbSecNoAccess could have a value of 20 in one
version and a value of -1 in another version, but all code that uses the
dbSecNoAccess identifier will work regardless of which version of the enum
is in use. To fully qualify references to the PermissionEnum constants, use
something like the following.

lngSomeVariable = DAO.PermissionEnum.dbSecNoAcess.

Where lngSomeVariable is a long data type.

Again, bit-wise definitions do not appear to have any relevance to the
PermissionEnum constants, but it might be that some non-public, undocumented
scheme was defined for Microsoft's internal use for assigning values to
these constants, but I doubt it. Simply, the constants appear to be nothing
more than values to be used for comparisons with the permissions and
allpermissions properties of a container or document object. These
properties in turn are just a storage for the sum of permissions represented
by the PermissionEnum constants.

Glenn




I'm exploring the use of DAO to examine and set Access permissions. This
involves using intrinsic constants that define bits in a 20-bit mask. This
mask is referred to in Article 37 of the Access Security FAQ. A reference in
that article leads to a table that defines each of these constants. After
getting the decimal value of each constant and converting that value to
binary, I see that some of the constants represent an individual bit but
other constants represent a combination of bits. Some of the 20 bits aren't
used at all.

I've looked for a detailed explanation of the 20-bit mask, specifically what
each individual bit represents, but haven't been able to find it. If anyone
has this information, I'd appreciate receiving a copy. Thanks.

Gordon
 
You are missing his point. Some of the dbSec constants have a value
comprising a single bit. Others have a value comprising several bits. The OP
is asking, what is the meaning of those individual bits? It is not to do
with the issue of using enums or symbols instead of hard-coded values. :-)

TC
 
TC,

The original post states, "I've looked for a detailed explanation of the
20-bit mask, specifically what each individual bit represents, but haven't
been able to find it." The enum example that I posted provides a "detailed
explanation of the 20-bit mask." (20-radix 16 appears to be used by Gordon,
the poster.)

Gordon's remarks about the bit mask are in the context of the PermissionEnum
constants, not the permissions or allpermissions properties, a distinction
that is necessary to avoid confusion with the unclear meaning of his remark
that "some of the constants represent an individual bit but other constants
represent a combination of bits." All of the predefined PermissionEnum
constants are 32 bits. Each bit is a placeholder in radix 2, binary, and
within the context of the PermissionEnum constants, a mask's bits are
defined by the value obtained by logically summing one or more of these
constants, which fully explains the bit patterns of zeroes and ones.

For completeness, in my response to Gordon, I included remarks about the use
of enum constants because he is working directly with values assigned to
constants instead of the constant identifiers. He posted that he is,
"Exploring the use of DAO to examine and set Access permissions." Since he's
exploring with DAO, he's probably writing source code, and information about
the use of constant identifiers may be useful to him.

Since you missed the point of my post, Gordon is likely to miss it as well.
If you have a better way of explaining "the meaning of those individual
bits," post it

Glenn



You are missing his point. Some of the dbSec constants have a value
comprising a single bit. Others have a value comprising several bits. The OP
is asking, what is the meaning of those individual bits? It is not to do
with the issue of using enums or symbols instead of hard-coded values. :-)

TC
 
Glenn Tarpley said:
TC,

The original post states, "I've looked for a detailed explanation of the
20-bit mask, specifically what each individual bit represents, but haven't
been able to find it." The enum example that I posted provides a "detailed
explanation of the 20-bit mask." (20-radix 16 appears to be used by Gordon,
the poster.)

Gordon's remarks about the bit mask are in the context of the PermissionEnum
constants, not the permissions or allpermissions properties, a distinction
that is necessary to avoid confusion with the unclear meaning of his remark
that "some of the constants represent an individual bit but other constants
represent a combination of bits."
Click to expand...

But there is nothing unclear about that remark, at all. That remark is the
nub of the problem! The OP has noticed that certain permission constants
have a value comprising a single bit - eg. dbseccreate, dbsecdelete - but
certain other permission constants have values comprising two or more bits -
eg. dbsecretrievedata, dbsecwritedef, dbsecallpermissions. The OP wants to
know, what is the meaning of those >individual bits<.

IMO, you are assuming that the value of each individual bit, is documented
by means of a dbsec constant comprising that bit. But you are missing the
point (IMHO) that some >other< permission constant could >also< contain that
bit. So there is not a simple 1-to-1 mapping between the permission
constants, and the underlying bits.

The purpose of those >underlying individual bits< is nowhere documented,
AFAIK.

Cheers,
TC
 
TC,

Your last response to me combined with your first indicates that you're
responding to me on a subject that is not consistent with the goals of the
original post that started this thread, so I'll respond to you accordingly.

First, you should recognize that my response to Gordon was to him, not you.

Second, I do not need or want clarification about your perspective of the
binary values of the PermissonEnum constants with regard to individual bits
and how the original post perceives them. In my original post, I avoided
discussing the PermissionEnum constant values from your perspective because
it's full of faulty thinking that requires useless explanation. You on the
other hand embrace it, and for whatever reason, describe it to me in your
last response.

You start by saying that, "There is nothing unclear about 'Some of the
constants represent[ing] an individual bit but other constants
represent[ing] a combination of bits.'" The first part of the statement is
ambiguous in the context of the PermissionEnum constants with which it is
used. The statement that "Some of the constants represent an individual bit"
cannot be taken literally to apply to the proper use of the constants. The
other statement may be generally applied to all of the PermissionEnum
constants. The importance of these statements to us is that they are the
basis upon which responses to the original post were made. To make use of
the first statement, one has to leap to a perspective that gives the
statement credence by making incorrect use of the PermissionEnum constants.
You rely upon the incorrect use of the PermissionEnum constants to make your
points. I rely upon the correct use of the constants to make my points. In
both of your responses to me, you completely miss the distinction between
your approach and mine.
..
Therefore, in what follows, I respond to your recent remarks, not to explain
the PermissionEnum constants to you, but to contrast your approach with
mine.

But there is nothing unclear about that remark, at all. That remark is the
nub of the problem! The OP has noticed that certain permission constants
have a value comprising a single bit - eg. dbseccreate, dbsecdelete - but
certain other permission constants have values comprising two or more bits -
eg. dbsecretrievedata, dbsecwritedef, dbsecallpermissions.
================================

Every PermissionEnum constant value is represented in 32-bits. All
documentation that I have read on the subject of logical operations
performed on PermissionEnum constants implies the use of 32-bit operands and
32-bit storage. Storage is usually a 4-byte integer data type variable
and/or the permissions property, which is itself a long integer storage of
4-bytes. Correct use of the constants is documented in the context of
32-bits, not 1, not 2, not fewer than 32 bits.


The OP wants to know, what is the meaning of those >individual bits<.
==============================================
For a binary PermissionEnum constant value, a specific bit is a placeholder
within a double word storage. A bit will be zero or one depending on the
value stored. In the context of my approach making correct use of the
constants, a stored value can be one of the PermissionEnum constant values
or a value derived from logical operations that use PermissionEnum constants
as operands.


IMO, you are assuming that the value of each individual bit, is documented
by means of a dbsec constant comprising that bit.
============================

Here you have difficulty expressing your opinion. Your statement borders on
nonsense because you are relying on the incorrect use of the PermissionEnum
constants to make your point. I don't have to assume because I know that
"the value of each individual bit is documented" by the PermissionEnum
constants that are normally expressed in base 10 and/or base 16.
Documentation for these constants applies to them regardless of the number
base.


But you are missing the
point (IMHO) that some >other< permission constant could >also< contain that
bit. So there is not a simple 1-to-1 mapping between the permission
constants, and the underlying bits.
*************************************
TC, I have to believe that you expect that sentence to be taken seriously
because you wrote it, but it's nonsense. As good as you are at getting the
point of things, this point should be easy for you: All of the
PermissionEnum constants are 32-bits. Furthermore, with your approach to
this topic, there is nothing special about binary. Such nonsense can be
applied to placeholders of any number base.


The purpose of those >underlying individual bits< is nowhere documented,
==================================

"The purpose of those underlying individual bits is" for each to store a
value of 0 or 1 depending on the value of the double word, which is either a
PermissionEnum constant or a logical sum of them as discussed further above.
The PermissionEnum constants are well documented, and in his original post,
Gordon refers to "Article 37 of the Access Security FAQ" and "a table that
defines each of these [PemissionEnum] constants," so he probably already has
what he asked for, "A detailed explanation of the 20-bit mask, specifically
what each individual bit represents"?

TC, I don't know you, so I measure your intent by what you have said. My
impression is that you have a shallow understanding of what you read in my
post. Yet, you respond to me claiming to have insight into points that you
believe I've missed. My first response to you should have been sufficient
for you to recognize your own oversights, but evidently, you read it with
the same shallow attention given to my first post. I respected your initial
remarks by explaining myself. That was a courtesy extended to you, not a
defense of my approach.

There may be future opportunities for us to discuss other topics to which
you might be able to lend some substance. In the mean time, please stop
worrying that I may miss some point that you want to make. You have to trust
that people can see what you are not missing TC. Otherwise, you might worry
yourself into a frenzy. There are surely better ways for you to expend your
energy.


Glenn






Glenn Tarpley said:
TC,

The original post states, "I've looked for a detailed explanation of the
20-bit mask, specifically what each individual bit represents, but haven't
been able to find it." The enum example that I posted provides a "detailed
explanation of the 20-bit mask." (20-radix 16 appears to be used by Gordon,
the poster.)

Gordon's remarks about the bit mask are in the context of the PermissionEnum
constants, not the permissions or allpermissions properties, a distinction
that is necessary to avoid confusion with the unclear meaning of his remark
that "some of the constants represent an individual bit but other constants
represent a combination of bits."
Click to expand...

But there is nothing unclear about that remark, at all. That remark is the
nub of the problem! The OP has noticed that certain permission constants
have a value comprising a single bit - eg. dbseccreate, dbsecdelete - but
certain other permission constants have values comprising two or more bits -
eg. dbsecretrievedata, dbsecwritedef, dbsecallpermissions. The OP wants to
know, what is the meaning of those >individual bits<.

IMO, you are assuming that the value of each individual bit, is documented
by means of a dbsec constant comprising that bit. But you are missing the
point (IMHO) that some >other< permission constant could >also< contain that
bit. So there is not a simple 1-to-1 mapping between the permission
constants, and the underlying bits.

The purpose of those >underlying individual bits< is nowhere documented,
AFAIK.

Cheers,
TC
 
Glen, most of what you have written below is completely irrelevant to the
issue in question. You misunderstood the OP's post. You still misunderstand
the OP's post! Your understanding of these issues is clearly still at a
"book learning" level. I suspect you have done little if any work at the
actual bits & bytes level of Jet.

So let's agree to disagree!

Bye,
TC


Glenn Tarpley said:
TC,

Your last response to me combined with your first indicates that you're
responding to me on a subject that is not consistent with the goals of the
original post that started this thread, so I'll respond to you accordingly.

First, you should recognize that my response to Gordon was to him, not you.

Second, I do not need or want clarification about your perspective of the
binary values of the PermissonEnum constants with regard to individual bits
and how the original post perceives them. In my original post, I avoided
discussing the PermissionEnum constant values from your perspective because
it's full of faulty thinking that requires useless explanation. You on the
other hand embrace it, and for whatever reason, describe it to me in your
last response.

You start by saying that, "There is nothing unclear about 'Some of the
constants represent[ing] an individual bit but other constants
represent[ing] a combination of bits.'" The first part of the statement is
ambiguous in the context of the PermissionEnum constants with which it is
used. The statement that "Some of the constants represent an individual bit"
cannot be taken literally to apply to the proper use of the constants. The
other statement may be generally applied to all of the PermissionEnum
constants. The importance of these statements to us is that they are the
basis upon which responses to the original post were made. To make use of
the first statement, one has to leap to a perspective that gives the
statement credence by making incorrect use of the PermissionEnum constants.
You rely upon the incorrect use of the PermissionEnum constants to make your
points. I rely upon the correct use of the constants to make my points. In
both of your responses to me, you completely miss the distinction between
your approach and mine.
.
Therefore, in what follows, I respond to your recent remarks, not to explain
the PermissionEnum constants to you, but to contrast your approach with
mine.

But there is nothing unclear about that remark, at all. That remark is the
nub of the problem! The OP has noticed that certain permission constants
have a value comprising a single bit - eg. dbseccreate, dbsecdelete - but
certain other permission constants have values comprising two or more bits -
eg. dbsecretrievedata, dbsecwritedef, dbsecallpermissions.
================================

Every PermissionEnum constant value is represented in 32-bits. All
documentation that I have read on the subject of logical operations
performed on PermissionEnum constants implies the use of 32-bit operands and
32-bit storage. Storage is usually a 4-byte integer data type variable
and/or the permissions property, which is itself a long integer storage of
4-bytes. Correct use of the constants is documented in the context of
32-bits, not 1, not 2, not fewer than 32 bits.


The OP wants to know, what is the meaning of those >individual bits<.
==============================================
For a binary PermissionEnum constant value, a specific bit is a placeholder
within a double word storage. A bit will be zero or one depending on the
value stored. In the context of my approach making correct use of the
constants, a stored value can be one of the PermissionEnum constant values
or a value derived from logical operations that use PermissionEnum constants
as operands.


IMO, you are assuming that the value of each individual bit, is documented
by means of a dbsec constant comprising that bit.
============================

Here you have difficulty expressing your opinion. Your statement borders on
nonsense because you are relying on the incorrect use of the PermissionEnum
constants to make your point. I don't have to assume because I know that
"the value of each individual bit is documented" by the PermissionEnum
constants that are normally expressed in base 10 and/or base 16.
Documentation for these constants applies to them regardless of the number
base.


But you are missing the
point (IMHO) that some >other< permission constant could >also< contain that
bit. So there is not a simple 1-to-1 mapping between the permission
constants, and the underlying bits.
*************************************
TC, I have to believe that you expect that sentence to be taken seriously
because you wrote it, but it's nonsense. As good as you are at getting the
point of things, this point should be easy for you: All of the
PermissionEnum constants are 32-bits. Furthermore, with your approach to
this topic, there is nothing special about binary. Such nonsense can be
applied to placeholders of any number base.


The purpose of those >underlying individual bits< is nowhere documented,
==================================

"The purpose of those underlying individual bits is" for each to store a
value of 0 or 1 depending on the value of the double word, which is either a
PermissionEnum constant or a logical sum of them as discussed further above.
The PermissionEnum constants are well documented, and in his original post,
Gordon refers to "Article 37 of the Access Security FAQ" and "a table that
defines each of these [PemissionEnum] constants," so he probably already has
what he asked for, "A detailed explanation of the 20-bit mask, specifically
what each individual bit represents"?

TC, I don't know you, so I measure your intent by what you have said. My
impression is that you have a shallow understanding of what you read in my
post. Yet, you respond to me claiming to have insight into points that you
believe I've missed. My first response to you should have been sufficient
for you to recognize your own oversights, but evidently, you read it with
the same shallow attention given to my first post. I respected your initial
remarks by explaining myself. That was a courtesy extended to you, not a
defense of my approach.

There may be future opportunities for us to discuss other topics to which
you might be able to lend some substance. In the mean time, please stop
worrying that I may miss some point that you want to make. You have to trust
that people can see what you are not missing TC. Otherwise, you might worry
yourself into a frenzy. There are surely better ways for you to expend your
energy.


Glenn






Glenn Tarpley said:
TC,

The original post states, "I've looked for a detailed explanation of the
20-bit mask, specifically what each individual bit represents, but haven't
been able to find it." The enum example that I posted provides a "detailed
explanation of the 20-bit mask." (20-radix 16 appears to be used by Gordon,
the poster.)

Gordon's remarks about the bit mask are in the context of the PermissionEnum
constants, not the permissions or allpermissions properties, a distinction
that is necessary to avoid confusion with the unclear meaning of his remark
that "some of the constants represent an individual bit but other constants
represent a combination of bits."
Click to expand...

But there is nothing unclear about that remark, at all. That remark is the
nub of the problem! The OP has noticed that certain permission constants
have a value comprising a single bit - eg. dbseccreate, dbsecdelete - but
certain other permission constants have values comprising two or more bits -
eg. dbsecretrievedata, dbsecwritedef, dbsecallpermissions. The OP wants to
know, what is the meaning of those >individual bits<.

IMO, you are assuming that the value of each individual bit, is documented
by means of a dbsec constant comprising that bit. But you are missing the
point (IMHO) that some >other< permission constant could >also< contain that
bit. So there is not a simple 1-to-1 mapping between the permission
constants, and the underlying bits.

The purpose of those >underlying individual bits< is nowhere documented,
AFAIK.

Cheers,
TC

All of the predefined PermissionEnum
constants are 32 bits. Each bit is a placeholder in radix 2, binary, and
within the context of the PermissionEnum constants, a mask's bits are
defined by the value obtained by logically summing one or more of these
constants, which fully explains the bit patterns of zeroes and ones.

For completeness, in my response to Gordon, I included remarks about the use
of enum constants because he is working directly with values assigned to
constants instead of the constant identifiers. He posted that he is,
"Exploring the use of DAO to examine and set Access permissions." Since he's
exploring with DAO, he's probably writing source code, and information about
the use of constant identifiers may be useful to him.

Since you missed the point of my post, Gordon is likely to miss it as well.
If you have a better way of explaining "the meaning of those individual
bits," post it

Glenn



You are missing his point. Some of the dbSec constants have a value
comprising a single bit. Others have a value comprising several bits.
Click to expand...
The
OP
is asking, what is the meaning of those individual bits? It is not to do
with the issue of using enums or symbols instead of hard-coded values. :-)

TC



defined.
The easy
way
Click to expand...
of
an constants,
use reference specifically
what
Click to expand...
Click to expand...
 
Back
Top