Problems with running assemblies (Ionic.Zip or SharpZipLib)

Posted by MarkT on 19-Jun-2019 15:32

Hi All,

I am on OpenEdge 10.2b and trying to make use of some .net dlls - Ionic.Zip specifically but I have also tried SharpZip.  I copy the dlls into my control directory - then add the referenced assemblies to the project by clicking properties on the project -> openedge ->assemblies and Add (then I browse for the files using the local assemblies tab).  This adds an assemblies.xml file into my control directory with the following:

<assembly name="ICSharpCode.SharpZipLib, Version=0.86.0.518, Culture=neutral, PublicKeyToken=1b03e6acf1164f73"/>

<assembly name="Ionic.Zip, Version=1.9.1.8, Culture=neutral, PublicKeyToken=edbe51ad942a3f5c"/>

I'm then able to write some code against them and it all works fine:

USING Ionic.Zip.ZipFile.
DEFINE VARIABLE class1 AS CLASS ZipFile.
class1 = NEW ZipFile("c:\temp\ionictest.zip").
class1:AddDirectory("C:\Temp\TestDir").
class1:Save().

Then I move on to making use of this within a local copy of our application - which again works fine and does what is expected.

However, when I try and make use of this on our QA system after copying the dlls and assemblies.xml files into their control directory I keep getting a security error:

"System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib,

Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed."

If I open a procedure editor on that system and try and syntax check the code it all seems fine - however running the code within the application just doesn't seem to work.  Are the assemblies in the wrong place?  Have I missed out a step?  The dlls are not being blocked - I have checked the properties of them.

Does anyone have any ideas?

Thanks,

Mark

All Replies

Posted by dbeavon on 19-Jun-2019 15:49

Can you write a quick console program in C# itself that makes use of the assemblies, and attempts the same operation?  It isn't necessarily an ABL problem and you might be able to determine whether that is the case or not .

Can you enable 4GLTrace logging and see where the problem starts?  I'd also suggest capturing as much of the stack trace as possible (via -errorstack documentation.progress.com/.../index.html  )

Sometimes the location of the error in the callstack is the biggest clue to the root cause.  Ideally you would have both the ABL stack and the .Net stack.

As I said earlier, this isn't necessarily an ABL or OpenEdge problem.  Your error appears like a pretty basic security permissions issue.  Can you run procmon (sysinternals) as administrator on the QA system and see what it says at the moment when the File I/O is attempted?  The security context of your QA system may be different in some subtle way.

Posted by dbeavon on 19-Jun-2019 16:02

Also what kind of container is hosting the application?  A windows full-client application?  A PASOE tomcat service?  A web application of some kind?

It looks like the exception (System.Security.Permissions.FileIOPermission) may be related to code access security in .net.  I'd check on the user account which is running the process has enough rights to access the file system, and you may also need to configure the assemblies to be fully trusted.

If this is related to code access security, you should be able to google that exception and find some solutions on stackoverflow.

Posted by MarkT on 20-Jun-2019 10:04

Thanks for replying - I have to .Net stack trace (below) - it is a windows full-client application.

.NET StackTrace:

-->   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)

  at System.Security.CodeAccessPermission.Demand()

  at System.IO.Directory.InternalGetFileDirectoryNames(String path, String userPathOriginal, String searchPattern, Boolean includeFiles, Boolean includeDirs, SearchOption searchOption)

  at System.IO.Directory.GetFiles(String path, String searchPattern, SearchOption searchOption)

  at System.IO.Directory.GetFiles(String path)

  at Ionic.Zip.ZipFile.AddOrUpdateDirectoryImpl(String directoryName, String rootDirectoryPathInArchive, AddOrUpdateAction action, Boolean recurse, Int32 level)

  at Ionic.Zip.ZipFile.AddOrUpdateDirectoryImpl(String directoryName, String rootDirectoryPathInArchive, AddOrUpdateAction action)

  at Ionic.Zip.ZipFile.AddDirectory(String directoryName)

Posted by dbeavon on 20-Jun-2019 13:17

It looks like the program is only partially trusted and is restricting itself on its ability to read files.  Normally this Code Access Security (CAS) is used for restricting third-party applications from doing untrusted things, *even* when they are running in the context of of an trusted executable that can do a lot more.  I don't know that much about CAS except that I'm often in a position like you where I'm trying to *disable* it or circumvent it in some way.  It is normally just a matter of reconfiguring the hosting application or the reconfiguring the Windows policy (see caspol.exe).  Or moving the application off of a partially trusted location (eg. off of a network share).

Here is a link that may give some more details.

stackoverflow.com/.../is-code-access-security-of-any-real-world-use

Is there a team at your company that is *deliberately* trying to restrict your application from accessing files?  It might be better to work with them before trying to subvert their restrictions.

Otherwise could you could test your app by moving the program files?   Are they on a network share or something?

Posted by MarkT on 20-Jun-2019 14:44

It does seem that someone has gone to a lot of trouble to make it difficult for me.. :)

The control directory is a network share, yes - I imagine that can't help!

I found this but I don't have permissions to try it so have put a request in with the network teams.

docs.microsoft.com/.../running-intranet-applications-in-full-trust

Think that could work?

Posted by dbeavon on 20-Jun-2019 20:50

I think you are on the right track.  Before you try getting the app working on the network, ask someone to copy it to a local drive and see if it would run properly from there. (Or write a smallish unit-test application that you can run in both places to confirm that it is a CAS issue).  If you are on the same network then I would guess the same policies apply to whatever workstation you are developing on so ... maybe you could just test both scenarios yourself, independently of the network team.  

It always helps to understand how things work before giving another team a suggestion for making changes.  Or maybe they will give you their suggestion, if it was their idea in the first place to host the application in a file share.  Personally I don't like running .Net framework applications on the network.  It might work 99.9% of the time and then fail in unusual ways when there are network blips.

This thread is closed