home *** CD-ROM | disk | FTP | other *** search
/ PC World 2000 August / PCWorld_2000-08_cd.bin / Software / TemaCD / freedos / full.bin / SOURCE / UNZ532 / PROGINFO / NT.SD < prev    next >
Text File  |  1997-01-11  |  6KB  |  112 lines
  1. Info-ZIP portable Zip/UnZip Windows NT security descriptor support
  2. ==================================================================
  3. Scott Field (sfield@microsoft.com), 8 October 1996
  4.  
  5.  
  6. This version of Info-ZIP's Win32 code allows for processing of Windows
  7. NT security descriptors if they were saved in the .zip file using the
  8. appropriate Win32 Zip running under Windows NT.  This also requires
  9. that the file system that Zip/UnZip operates on supports persistent 
  10. Acl storage.  When the operating system is not Windows NT and the 
  11. target file system does not support persistent Acl storage, no security
  12. descriptor processing takes place.
  13.  
  14. A Windows NT security descriptor consists of any combination of the
  15. following components:
  16.  
  17.        an owner (Sid)
  18.        a primary group (Sid)
  19.        a discretionary ACL (Dacl)
  20.        a system ACL (Sacl)
  21.        qualifiers for the preceding items
  22.  
  23. By default, Zip will save all aspects of the security descriptor except
  24. for the Sacl.  The Sacl contains information pertaining to auditing of
  25. the file, and requires a security privilege be granted to the calling
  26. user in addition to being enabled by the calling application.  In order
  27. to save the Sacl during Zip, the user must specify the -! switch on the
  28. Zip commandline.  The user must also be granted either the SeBackupPrivilege
  29. "Backup files and directories" or the SeSystemSecurityPrivilege "Manage
  30. auditing and security log".
  31.  
  32. By default, UnZip will not restore any aspects of the security descriptor.
  33. If the -X option is specified to UnZip, the Dacl is restored to the file.
  34. The other items in the security descriptor on the new file will receive
  35. default values.  If the -XX option is specified to UnZip, as many aspects
  36. of the security descriptor as possible will be restored.  If the calling
  37. user is granted the SeRestorePrivilege "Restore files and directories",
  38. all aspects of the security descriptor will be restored.  If the calling
  39. user is only granted the SeSystemSecurityPrivilege "Manage auditing and
  40. security log", only the Dacl and Sacl will be restored to the new file.
  41.  
  42. Note that when operating on files that reside on remote volumes, the 
  43. privileges specified above must be granted to the calling user on that
  44. remote machine.  Currently, there is no way to directly test what privileges
  45. are present on a remote machine, so Zip and UnZip make a remote privilege
  46. determination based on an indirect method.
  47.  
  48. UnZip considerations
  49. --------------------
  50.  
  51. In order for file security to be processed correctly, any directory entries
  52. that have a security descriptor will be processed at the end of the unzip
  53. cycle.  This allows for unzip to process files within the newly created
  54. directory regardless of the security descriptor associated with the directory
  55. entry.  This also prevents security inheritance problems that can occur as
  56. a result of creating a new directory and then creating files in that directory
  57. that will inherit parent directory permissions; such inherited permissions may
  58. prevent the security descriptor taken from the zip file from being applied
  59. to the new file.
  60.  
  61. If directories exist which match directory/extract paths in the .zip file,
  62. file security is not updated on the target directory.  It is assumed that if
  63. the target directory already exists, then appropriate security has already
  64. been applied to that directory.
  65.  
  66. "unzip -t" will test the integrity of stored security descriptors when 
  67. present and the operating system is Windows NT.
  68.  
  69. ZipInfo (unzip -Z) will display information on stored security descriptor 
  70. when "unzip -Zv" is specifed.
  71.  
  72.  
  73. Potential uses
  74. ==============
  75.  
  76. The obvious use for this new support is to better support backup and restore
  77. operations in a Windows NT environment where NTFS file security is utilized.
  78. This allows individuals and organizations to archive files in a portable
  79. fashion and transport these files across the organization.
  80.  
  81. Another potential use of this support is setup and installation.  This 
  82. allows for distribution of Windows NT based applications that have preset
  83. security on files and directories.  For example, prior to creation of the 
  84. .zip file, the user can set file security via File Manager or Explorer on
  85. the files to be contained in the .zip file.  In many cases, it is appropriate
  86. to only grant Everyone Read access to .exe and .dll files, while granting
  87. Administrators Full control.  Using this support in conjunction with the
  88. unzipsfx.exe self-extractor stub can yield a useful and powerful way to
  89. install software with preset security (note that -X or -XX should be 
  90. specified on the self-extractor commandline).
  91.  
  92. When creating .zip files with security which are intended for transport 
  93. across systems, it is important to take into account the relevance of 
  94. access control entries and the associated Sid of each entry.  For example,
  95. if a .zip file is created on a Windows NT workstation, and file security 
  96. references local workstation user accounts (like an account named Fred), 
  97. this access entry will not be relevant if the .zip file is transported to 
  98. another machine.  Where possible, take advantage of the built-in well-known 
  99. groups, like Administrators, Everyone, Network, Guests, etc.  These groups
  100. have the same meaning on any Windows NT machine.  Note that the names of
  101. these groups may differ depending on the language of the installed Windows
  102. NT, but this isn't a problem since each name has well-known ID that, upon
  103. restore, translates to the correct group name regardless of locale.
  104.  
  105. When access control entries contain Sid entries that reference Domain 
  106. accounts, these entries will only be relevant on systems that recognize 
  107. the referenced domain.  Generally speaking, the only side effects of 
  108. irrelevant access control entries is wasted space in the stored security 
  109. descriptor and loss of complete intended access control.  Such irrelevant 
  110. access control entries will show up as "Account Unknown" when viewing file 
  111. security with File Manager or Explorer.
  112.