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