Changeset 87 for trunk/doc/reglookup.1.docbook
- Timestamp:
- 02/03/07 20:55:18 (18 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/reglookup.1.docbook
r72 r87 165 165 <para> 166 166 <!-- XXX: this should be a bit more formal --> 167 <command>reglookup</command> generates acomma-separated values (CSV)168 compatible formatto stdout. The format is designed to simplify parsing167 <command>reglookup</command> generates comma-separated values (CSV) 168 and writes them to stdout. The format is designed to simplify parsing 169 169 algorithms of other tools by quoting CSV special characters using a 170 170 common hexadecimal format. Specifically, special characters or non-ascii 171 171 bytes are converted to "\xQQ" where QQ is the hexadecimal value for 172 172 the byte. 173 </para> 174 <para> 175 The number of columns or fields in each line is fixed for a given run 176 of the program, but may vary based on the command line options provided. 177 See the header line for information on which fields are available and 178 what they contain. 179 </para> 180 <para> 181 Some fields in some lines may contain sub-fields which require additional 182 delimiters. If these sub-delimiters occur in these sub-fields, they are 183 also encoded in the same way as commas or other special characters are. 184 Currently, the second, third, and fourth level delimiters are "|", ":", 185 and " ", respectively. These are particularly important to take note of 186 when security attributes are printed. Please note that these delimiters 187 may occur in fields that are not sub-delimited, and should not be 188 interpreted as special. 189 </para> 190 <para> 191 Security attributes of registry keys have a complex structure which is 192 outlined here. Each key will generally have an associated ACL (Access 193 Control List), which is made up of ACEs (Access Control Entries). Each 194 ACE is delimited by the secondary delimiter mentioned above, "|". The 195 fields within an ACE are delimited by the third-level delimiter, ":", 196 and consist of a SID, the ACE type (ALLOW, DENY, etc), a list of access 197 rights, and a list of flags. The last two fields are delimited by the 198 fourth-level delimiter " ". These final lists are simply human-readable 199 interpretations of bits. The access rights abbreviations are listed 200 below along with their Microsoft-assigned names: 201 <screen> 202 QRY_VAL KEY_QUERY_VALUE 203 SET_VAL KEY_SET_VALUE 204 CREATE_KEY KEY_CREATE_SUB_KEY 205 ENUM_KEYS KEY_ENUMERATE_SUB_KEYS 206 NOTIFY KEY_NOTIFY 207 CREATE_LNK KEY_CREATE_LINK 208 WOW64_64 KEY_WOW64_64KEY 209 WOW64_32 KEY_WOW64_32KEY 210 DELETE DELETE 211 R_CONT READ_CONTROL 212 W_DAC WRITE_DAC 213 W_OWNER WRITE_OWNER 214 SYNC SYNCHRONIZE 215 SYS_SEC ACCESS_SYSTEM_SECURITY 216 MAX_ALLWD MAXIMUM_ALLOWED 217 GEN_A GENERIC_ALL 218 GEN_X GENERIC_EXECUTE 219 GEN_W GENERIC_WRITE 220 GEN_R GENERIC_READ 221 </screen> 222 223 And the meaning of each flag is: 224 <screen> 225 OI Object Inherit 226 CI Container Inherit 227 NP Non-Propagate 228 IO Inherit Only 229 IA Inherited ACE 230 </screen> 231 232 Please see the following references for more information: 233 <screen> 234 http://msdn2.microsoft.com/en-gb/library/ms724878.aspx 235 http://msdn2.microsoft.com/en-gb/library/aa374892.aspx 236 http://msdn2.microsoft.com/en-us/library/aa772242.aspx 237 http://support.microsoft.com/kb/220167 238 </screen> 239 </para> 240 <para> 241 Note that some of the bits listed above have either not been allocated by 242 Microsoft, or simply aren't documented. If any bits are set in the above 243 two fields that aren't recognized, a hexidecimal representation of all of 244 these mystery bits will be included in the output. For instance, if the 245 lowest bit and third lowest bit were not recognized while being set, 246 the number "0x5" would be included as an element in the list. 247 </para> 248 <para> 249 While the ACL/ACE output format is mostly stable at this point, minor 250 changes may be introduced in future versions. 173 251 </para> 174 252 </refsect1> … … 240 318 <para> 241 319 You'll notice that registry paths aren't all the same as the 242 equivalents you see in the windows registry editor. Don't ask me why243 that is. I just work here.244 </para>245 <para>246 This software should be considered unstable at this time.320 equivalents you see in the windows registry editor. This is because 321 Windows constructs the registry view from multiple registry files, 322 each with their own roots. This utility merely shows what exists 323 under a single root. This isn't really a bug, but one should be 324 aware of the differences in path. 247 325 </para> 248 326 </refsect1>
Note: See TracChangeset
for help on using the changeset viewer.