Package.Open Requested registry access is not allowed

Question

We are calling System.IO.Packaging.Package.Open() in an ASP.NET application. Further, a Windows impersonation has been performed before calling this because the package to be opened is stored in a secure location and the impersonation is required in order to read it.

The problem is that Package.Open() calls EventTrace.EasyTraceEvent() which in turn calls MS.Utility.EventTrace.IsClassicETWRegistryEnabled() which throws a security exception of Requested registry access is not allowed.

This occurs even if is specifically disabled in Web.config . In both Debug and Release mode.

Thus my dilemma. The impersonation is required because the file (package) is stored such that it is only accessible by the impersonated account. Copying it to an insecure location would defeat the purpose of the security.

Granting the impersonated account access to the registry opens a security hole in the other direction. This account does not have nor otherwise need any access to any other system resources beyond a specific set of files and folders.

What I really want is for EventTrace to take a flying leap off a cliff, but I don't know how to tell it to do that.

Any ideas?

Answer 1

Short answer: Use a stream. Do impersonation to open the stream, end the impersonation, and then pass the still-open stream to Package.Open().

Long answer:

• The source of the error is the static class initializer for EventTrace. It calls IsClassicETWRegistryEnabled() which in turn accesses the registry. Since it is in the class initializer it means that there is no way to disable it and that EventTrace is fundamentally broken when it comes to Impersonation.

• Package.Open() is really a wrapper around "new ZipPackage()".

• ZipPackage is a sealed implementation of the Package abstract class.

• ZipPackage has no public constructors.

• ZipPackage in turn uses internal methods on ZipArchive which is in the MS.Internal.IO.Zip namespace and is also a sealed class.

Conclusions:

• System.IO.Packaging has issues with Impersonation when that impersonation doesn't have sufficient registry access.

• System.IO.Packaging should be looked at as a private Microsoft namespace, not a public one.

Options:

• Move the file out of a secure area so that impersonation is not necessary.

• Load the file when impersonation is not necessary and store the data some other way (ex: in a DB)).

• Open a stream under impersonation, end the impersonation, and then use Package.Open() on the stream.

If anyone is curious the packages we are reading are Visio 2013 VSDX files.