f0d81ffd1c
which included commits to RCS files with non-trunk default branches. git-svn-id: svn://10.65.10.50/trunk@5403 c028cbd2-c16b-5b4b-a496-9718f37d4682
112 lines
5.8 KiB
Plaintext
Executable File
112 lines
5.8 KiB
Plaintext
Executable File
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.
|