Info-ZIP portable Zip/UnZip Windows NT security descriptor support
==================================================================
Scott Field (sfield@microsoft.com), 8 October 1996
This version of Info-ZIP's Win32 code allows for processing of Windows
NT security descriptors if they were saved in the .zip file using the
appropriate Win32 Zip running under Windows NT. This also requires
that the file system that Zip/UnZip operates on supports persistent
Acl storage. When the operating system is not Windows NT and the
target file system does not support persistent Acl storage, no security
descriptor processing takes place.
A Windows NT security descriptor consists of any combination of the
following components:
an owner (Sid)
a primary group (Sid)
a discretionary ACL (Dacl)
a system ACL (Sacl)
qualifiers for the preceding items
By default, Zip will save all aspects of the security descriptor except
for the Sacl. The Sacl contains information pertaining to auditing of
the file, and requires a security privilege be granted to the calling
user in addition to being enabled by the calling application. In order
to save the Sacl during Zip, the user must specify the -! switch on the
Zip commandline. The user must also be granted either the SeBackupPrivilege
"Backup files and directories" or the SeSystemSecurityPrivilege "Manage
auditing 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 receive
default values. If the -XX option is specified to UnZip, as many aspects
of the security descriptor as possible will be restored. If the calling
user is granted the SeRestorePrivilege "Restore files and directories",
all aspects of the security descriptor will be restored. If the calling
user is only granted the SeSystemSecurityPrivilege "Manage auditing and
security log", only the Dacl and Sacl will be restored to the new file.
Note that when operating on files that reside on remote volumes, the
privileges specified above must be granted to the calling user on that
remote machine. Currently, there is no way to directly test what privileges
are present on a remote machine, so Zip and UnZip make a remote privilege
determination based on an indirect method.
UnZip considerations
--------------------
In order for file security to be processed correctly, any directory entries
that have a security descriptor will be processed at the end of the unzip
cycle. This allows for unzip to process files within the newly created
directory regardless of the security descriptor associated with the directory
entry. This also prevents security inheritance problems that can occur as
a result of creating a new directory and then creating files in that directory
that will inherit parent directory permissions; such inherited permissions may
prevent the security descriptor taken from the zip file from being applied
to 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 if
the target directory already exists, then appropriate security has already
been applied to that directory.
"unzip -t" will test the integrity of stored security descriptors when
present and the operating system is Windows NT.
ZipInfo (unzip -Z) will display information on stored security descriptor
when "unzip -Zv" is specifed.
Potential uses
==============
The obvious use for this new support is to better support backup and restore
operations in a Windows NT environment where NTFS file security is utilized.
This allows individuals and organizations to archive files in a portable
fashion and transport these files across the organization.
Another potential use of this support is setup and installation. This
allows for distribution of Windows NT based applications that have preset
security on files and directories. For example, prior to creation of the
.zip file, the user can set file security via File Manager or Explorer on
the files to be contained in the .zip file. In many cases, it is appropriate
to only grant Everyone Read access to .exe and .dll files, while granting
Administrators Full control. Using this support in conjunction with the
unzipsfx.exe self-extractor stub can yield a useful and powerful way to
install software with preset security (note that -X or -XX should be
specified on the self-extractor commandline).
When creating .zip files with security which are intended for transport
across systems, it is important to take into account the relevance of
access control entries and the associated Sid of each entry. For example,
if a .zip file is created on a Windows NT workstation, and file security
references local workstation user accounts (like an account named Fred),
this access entry will not be relevant if the .zip file is transported to
another machine. Where possible, take advantage of the built-in well-known
groups, like Administrators, Everyone, Network, Guests, etc. These groups
have the same meaning on any Windows NT machine. Note that the names of
these groups may differ depending on the language of the installed Windows
NT, but this isn't a problem since each name has well-known ID that, upon
restore, translates to the correct group name regardless of locale.
When access control entries contain Sid entries that reference Domain
accounts, these entries will only be relevant on systems that recognize
the referenced domain. Generally speaking, the only side effects of
irrelevant access control entries is wasted space in the stored security
descriptor and loss of complete intended access control. Such irrelevant
access control entries will show up as "Account Unknown" when viewing file
security with File Manager or Explorer.