Info-ZIP portable Zip/UnZip Windows NT security descriptor support==================================================================Scott Field (sfield@microsoft.com), 8 October 1996This version of Info-ZIP's Win32 code allows for processing of WindowsNT security descriptors if they were saved in the .zip file using theappropriate Win32 Zip running under Windows NT.  This also requiresthat the file system that Zip/UnZip operates on supports persistentAcl storage.  When the operating system is not Windows NT and thetarget file system does not support persistent Acl storage, no securitydescriptor processing takes place.A Windows NT security descriptor consists of any combination of thefollowing components:       an owner (Sid)       a primary group (Sid)       a discretionary ACL (Dacl)       a system ACL (Sacl)       qualifiers for the preceding itemsBy default, Zip will save all aspects of the security descriptor exceptfor the Sacl.  The Sacl contains information pertaining to auditing ofthe file, and requires a security privilege be granted to the callinguser in addition to being enabled by the calling application.  In orderto save the Sacl during Zip, the user must specify the -! switch on theZip commandline.  The user must also be granted either the SeBackupPrivilege"Backup files and directories" or the SeSystemSecurityPrivilege "Manageauditing and security log".By default, UnZip will not restore any aspects of the security descriptor.If the -X option is specified to UnZip, the Dacl is restored to the file.The other items in the security descriptor on the new file will receivedefault values.  If the -XX option is specified to UnZip, as many aspectsof the security descriptor as possible will be restored.  If the callinguser is granted the SeRestorePrivilege "Restore files and directories",all aspects of the security descriptor will be restored.  If the callinguser is only granted the SeSystemSecurityPrivilege "Manage auditing andsecurity log", only the Dacl and Sacl will be restored to the new file.Note that when operating on files that reside on remote volumes, theprivileges specified above must be granted to the calling user on thatremote machine.  Currently, there is no way to directly test what privilegesare present on a remote machine, so Zip and UnZip make a remote privilegedetermination based on an indirect method.UnZip considerations--------------------In order for file security to be processed correctly, any directory entriesthat have a security descriptor will be processed at the end of the unzipcycle.  This allows for unzip to process files within the newly createddirectory regardless of the security descriptor associated with the directoryentry.  This also prevents security inheritance problems that can occur asa result of creating a new directory and then creating files in that directorythat will inherit parent directory permissions; such inherited permissions mayprevent the security descriptor taken from the zip file from being appliedto the new file.If directories exist which match directory/extract paths in the .zip file,file security is not updated on the target directory.  It is assumed that ifthe target directory already exists, then appropriate security has alreadybeen applied to that directory."unzip -t" will test the integrity of stored security descriptors whenpresent and the operating system is Windows NT.ZipInfo (unzip -Z) will display information on stored security descriptorwhen "unzip -Zv" is specifed.Potential uses==============The obvious use for this new support is to better support backup and restoreoperations in a Windows NT environment where NTFS file security is utilized.This allows individuals and organizations to archive files in a portablefashion and transport these files across the organization.Another potential use of this support is setup and installation.  Thisallows for distribution of Windows NT based applications that have presetsecurity on files and directories.  For example, prior to creation of the.zip file, the user can set file security via File Manager or Explorer onthe files to be contained in the .zip file.  In many cases, it is appropriateto only grant Everyone Read access to .exe and .dll files, while grantingAdministrators Full control.  Using this support in conjunction with theunzipsfx.exe self-extractor stub can yield a useful and powerful way toinstall software with preset security (note that -X or -XX should bespecified on the self-extractor commandline).When creating .zip files with security which are intended for transportacross systems, it is important to take into account the relevance ofaccess control entries and the associated Sid of each entry.  For example,if a .zip file is created on a Windows NT workstation, and file securityreferences local workstation user accounts (like an account named Fred),this access entry will not be relevant if the .zip file is transported toanother machine.  Where possible, take advantage of the built-in well-knowngroups, like Administrators, Everyone, Network, Guests, etc.  These groupshave the same meaning on any Windows NT machine.  Note that the names ofthese groups may differ depending on the language of the installed WindowsNT, but this isn't a problem since each name has well-known ID that, uponrestore, translates to the correct group name regardless of locale.When access control entries contain Sid entries that reference Domainaccounts, these entries will only be relevant on systems that recognizethe referenced domain.  Generally speaking, the only side effects ofirrelevant access control entries is wasted space in the stored securitydescriptor and loss of complete intended access control.  Such irrelevantaccess control entries will show up as "Account Unknown" when viewing filesecurity with File Manager or Explorer.