Getting file security information

[etippelt]

If I right click on a file in Explorer, and then select properties, followed by the security tab, I get a display of user groups who have permissions on that file, and by selecting a specific group or user name, I can find out what permissions that group or user has on the file. EG - Full Control, Modify, Read and Execute, etc.

Trying to get this information in my Winbatch script, I have extracted the list of group names using wntAccessList, but I am stuck on where to go next. I assume I need to run a command for each of the group names to extract their specific permissions but having trawled through the wntxxx commands in the Network Extender, I must be missing which of the commands I need next.

Any clues would be most welcome!

Thanks
EdT

[td]

Check out the wntAccessGet function in the Consolidated WIL help file.

[etippelt]

Thanks.

Note to the Winbatch documentation editors regarding wntAccessGet.
1. c:\winnt has not been the default windows folder for a LONG time - so might be worth updating any example references in the help file from C:\Winnt to C:\Windows

2. The group "Everyone" has also disappeared, with "Users" pretty much taking over in its place.

3. Some explanation of the way to decode the access records, or a pointer to the relevant MS docs would help. 0:0:1179817|0:11:-1610612736 is pretty meaningless on its own.  I suspect this information is in a .h file somewhere in the SDK, so I'm off to hunt it down, but meanwhile if anyone has any pointers, they would be most welcome....

Cheers - EdT

[etippelt]

OK, so I have had a hunt around but so far have been unable to find the decode for the information returned by wntAccessGet, eg:
C:\Windows user access records = 0:0:1179817|0:11:-1610612736|

There appear to be three fields in each returned record, separated by colons.  Cannot find the definition of these fields, but I suspect that the third field somehow relates to the long word definition of DACLs in Winnt.h
Would I be right in thinking that these numbers are in decimal rather than hex?  Also puzzled by the minus in the second figure - I've seen this in ones-complement binary figures but no so much on decimals.  If anyone can help with the decodes that would be most appreciated!
Thanks
EdT

[td]

2. The group "Everyone" has also disappeared, with "Users" pretty much taking over in its place.

The 'Everyone' group (well known SID  S-1-1-0) is still alive and well. It is certainly not the same thing as the 'user' group.  Perhaps some corporate IT departments don't like it but it is still an integral part of the OS.

[etippelt]

Not in the MSI packaging environment if you are using the Lockpermissions table. The group Everyone is no longer recognised. Apologies for the misleading statement however.

Any input on decoding the results of the wntAccessGet command?

Thanks
Ed

[td]

Not in the MSI packaging environment if you are using the Lockpermissions table. The group Everyone is no longer recognised. Apologies for the misleading statement however.

I am sure all the folks that work with MSI will keep that in mind when reading the extender's documentation...

C:\Windows user access records = 0:0:1179817|0:11:-1610612736|

Access record meanings are defined in the documentation for the wntAccessAdd function.  If you look there, you will see that your access string is granting access as both ACEs have a leading 0 for ACE type.  The first string does not have an ACE flag but the second indicates that it is object inheritable as (1), container inheritable (2), and inherit only (Ã,·8). These values are ORed together which results is the value 11.   The ACEs together grant directory read permission (1179817 and -1610612736).

Admittedly, it takes a bit of work to read access records but like many things, it gets easier with practice. 

[etippelt]

THANK YOU!
If you can hear the distant sound of head banging against wooden table, it's me...
I looked through many of the commands in the Win32 network extender and somehow missed this one.  Now I can see the entry in wntAccessGet that refers back to wntAccessAdd() for information on the format of the access records.  A case of 20-20 hindsight and too many interruptions.
Thanks again
Ed

[Deana]

OK, so I have had a hunt around but so far have been unable to find the decode for the information returned by wntAccessGet, eg:
C:\Windows user access records = 0:0:1179817|0:11:-1610612736|

There appear to be three fields in each returned record, separated by colons.  Cannot find the definition of these fields, but I suspect that the third field somehow relates to the long word definition of DACLs in Winnt.h
Would I be right in thinking that these numbers are in decimal rather than hex?  Also puzzled by the minus in the second figure - I've seen this in ones-complement binary figures but no so much on decimals.  If anyone can help with the decodes that would be most appreciated!
Thanks
EdT

See the WntAccessAdd function for the explanation of the 'access-records' values. Each record is in the format:

Code Select Expand


record-type:access-flags:access-rights


where 'record-type', 'access-flags', and 'access-rights' are each a decimal number, separated with colons ( : ).

For further explanation see the wntAccessAdd topic and read the section titled: B) Specific 'access-records'

[etippelt]

Thanks Deana - it all makes sense now, apart from one final thing...

I see values returned such as  ââ,¬Å"-267451905ââ,¬Â³ and ââ,¬Å"-536673793ââ,¬Â³.  I am assuming that at the binary level this is being treated as a signed integer, but having spent a couple of hours with the windows calculator in programming mode, trying to translate these numbers into something that makes sense, I'm not getting it. 
Any light you could shed on this would be most welcome....
Cheers
Ed

[td]

The help file description of the 'access-rights' item of an access string states, "Multiple access-rights values may be bit-wise OR'd together to combine them into a single access mask value."

What that means is that the access-rights are expressed as a series of bits.  Each bit or combination of bits in some cases indicates an access-right.  To determine if an access-right is set you need to bitwise OR the item with one of the rights listed in the help file tables.

For example, to determine if the generic read access right is present in the access string you would do something like this

Code (winbatch) Select Expand


GENERIC_READ = 2147483648
bGenericRead = 267451905&GENERIC_READ
if  bGenericRead then Message("Access-Rights","Generic read access")
else Message("Access-Rights","No generic read access")


[etippelt]

Are you saying that the minus in front of some returned values is to be ignored?
Even in the Winbatch documentation, the final bit is shown with a minus value.  However, as in real testing, somewhat smaller values are being returned with a minus in front of them, I'm trying to understand the significance of this.
Thanks
Ed

[ChuckC]

No, you don't ignore the negative sign and just take the absolute value of the number, as the binary representation of, say, 1 and -1 are *NOT* the same.

What you are observing is that WinBatch expresses the integer as a signed 32-bit value, while the underlying Win32 API functions [and their documentation] that deals with access-mask values in ACEs are using unsigned 32-bit integers.  It is a limitation of the WinBatch Studio debugger that you cannot get an unsigned representation of the number.  Any time that the most significant bit is set, the number will be displayed as a negative number.  For display purposes, such as when logging access-mask values to a log file or displaying them in a message box, I'd recommend converting them to a hexadecimal value in a string, and display the string instead.  Thus, -1 would be represented as FFFFFFFF, and -2,147,483,647 would be represented as 80000001, etc....

[td]

Chuck is quite correct.  The absence of a minus sign in the posted example was an unfortunate typo.  Sorry if the oversight caused any confusion. Should know better than to post untested scripts...

[etippelt]

I just tried the xBaseConvert sample code from the consolidated help file with one of the values returned by wntAccessGet.  I entered -1610612736 as the decimal value.
This returned -60000000 as the Hex value, and also -60000000 as the Binary value.  Correct me if I'm wrong but binary is just zeros and ones, so where did the 6 come from?
I repeated the test with 1610612736 and both HEX and Binary fields returned 60000000  (so no difference when dealing with signed values)
The code I used was:
; Load Appropriate Extender
AddExtender("wilx44i.dll",0,"wilx64i.dll")
dec = AskLine("Base conversion", "Enter a decimal value", 255)
hex = xBaseConvert(dec, 10, 16)
bin = xBaseConvert(dec, 10, 2)
Message("Base conversion", "Decimal: ":@TAB:dec:@CRLF:"Hex:":@TAB:hex:@CRLF:"Binary: ":@TAB:bin)

I used the debug option to run x64.

Just to cover all the bases, I tried with the 32 bit RUN option, and this time the binary value was correct - all 1s and 0s.

It therefore suggests to me that the wilx64i.dll has a bug in it. The file version on my system is showing as 41002.0.0.0

Following on from the earlier comments about converting the signed values to binary - at the moment the wilx extender is converting signed numbers with no regard for the minus, which seems contrary to what is required.  This is all getting quite confusing!!
Any further clarification on converting signed decimal numbers to binary would be most welcome!

Thanks
Ed

[td]

I just tried the xBaseConvert sample code from the consolidated help file with one of the values returned by wntAccessGet.  I entered -1610612736 as the decimal value.
This returned -60000000 as the Hex value, and also -60000000 as the Binary value.  Correct me if I'm wrong but binary is just zeros and ones, so where did the 6 come from?
I repeated the test with 1610612736 and both HEX and Binary fields returned 60000000  (so no difference when dealing with signed values)
The code I used was:
; Load Appropriate Extender
AddExtender("wilx44i.dll",0,"wilx64i.dll")
dec = AskLine("Base conversion", "Enter a decimal value", 255)
hex = xBaseConvert(dec, 10, 16)
bin = xBaseConvert(dec, 10, 2)
Message("Base conversion", "Decimal: ":@TAB:dec:@CRLF:"Hex:":@TAB:hex:@CRLF:"Binary: ":@TAB:bin)

I used the debug option to run x64.

Just to cover all the bases, I tried with the 32 bit RUN option, and this time the binary value was correct - all 1s and 0s.

It therefore suggests to me that the wilx64i.dll has a bug in it. The file version on my system is showing as 41002.0.0.0

Yes, the 64 bit version of the xBaseConvert does appear to have a memory corruption bug and thank you for reporting it. It must have been missed when the extender was ported to 64-bit.

Following on from the earlier comments about converting the signed values to binary - at the moment the wilx extender is converting signed numbers with no regard for the minus, which seems contrary to what is required.  This is all getting quite confusing!!
Any further clarification on converting signed decimal numbers to binary would be most welcome!

The xBaseConvert function converts numbers to base 2.  Base 2 numbers can be positive or negative just like decimal or hexadecimal numbers. However, Chuck's discussion above is about the two's complement representation of integers commonly used in computers because it is efficient.  In the two's complement representation, the most significant bit is treated as the sign bit.  When that bit is 1 the number is negative when viewed as a decimal signed integer.  When the same two's complement integer is viewed as an unsigned decimal number, it just becomes a very large integer value because the sign bit is treated as just another digit.

WinBatch always displays integer values as signed but that does not change the integer representation in memory nor does it affect the results of WinBatch bitwise operations on that integer.

It is a relatively trivial task to write a simple UDF to convert a number to it's two's complement representation but there is really no need to do so to make full use of access-string permissions.

[ChuckC]

Uh... binary != hexadecimal.

In the help topic for wntAccessAdd(), about 3/5 of the way down the page, there is a section that begins as follows:

'access-rights' (one or more of the following, usually several, depending on the object type.)

And in that section is a list of C/C++ macro names, such as FILE_READ_DATA, KEY_QUERY_VALUE, etc..., and with each macro name there are both decimal and hexadecimal representations of their values.

Each one of the pre-defined access strings that are documented earlier in that topic have their access-mask values computed by performing a binary [not logical] OR operation on these individual access-right bit values to result in a combined access-mask value.  Please note that a binary OR operation is not the same as addition, so you can't combine mask values simply by adding them together even though it may appear to be an addition operation when you are combining access-right values that are represented by single bit values.

The general purpose GENERIC_READ access-right bit has a hexadecimal value of 0x80000000, and an *unsigned* 32-bit integer decimal value of 2147483648.  Due to how decimal representations of a 32-bit integer value vary based on whether the number is signed or unsigned, any 32-bit integer with the high order bit [bit 31] set will be represented as a negative number when interpreted as a signed value.  Likewise, all of the other defined access-right values are represented by single bit values contained in bits 0 through 31.

The following article gives a nice explanation of how integers are handled on a computer and in various programming languages:

http://en.wikipedia.org/wiki/Integer_(computer_science)

[td]

For the curious:

Code (winbatch) Select Expand


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Returns the two's complement representation of a decimal integer
;; as a string of 1's and 0's.
#DefineFunction Dec2TwosComp( nDecInt )
strReturn = ""
for i = 31 to 0  by -1
   if nDecInt & (1<<i) then strReturn = strReturn:'1'
   else strReturn = strReturn:'0'
next
return strReturn
#EndFunction

;; Test
nDecimal = -16
strTwosComp = Dec2TwosComp(nDecimal)

Message("Two's Complement Representation", "Decimal: ":nDecimal:@CRLF:"Two's complement: ":strTwosComp)


[td]

More fun with the two's complement of a number (or negating a number the hard way.)

Code (winbatch) Select Expand


x = 16
y = (x ^ -1) + 1
Message("Two's Complement", "Two's complement of ":x:" is ":y)