[Mono-dev] Compiling and executing untrusted code from a managed application
I want to be able to compile and execute untrusted code at runtime from within a managed (C#) application. I have accomplished this in .NET by compiling the code to an assembly on disk, creating a new AppDomain with a limited permission set, and loading the compiled assembly into that domain. Unfortunately this does not work in Mono; the limited permissions are not respected and the dangerous code runs successfully. There is something called the Mono Sandbox, but it apparently has to be enabled by the unmanaged host of the managed runtime. I am looking for a solution that only involved managed code. The only thing I have come up with so far is analyzing the compiled code with Mono.Cecil and looking for anything dangerous. Is there a more straightforward solution for this that I am missing? Thanks, David ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] What will happen if Dispose() hangs?
When I call SslStream.Dispose(), the thread simply hangs indefinitely. (Well, I didn't wait forever; only a few minutes, which is longer than the underlying TcpClient timeout periods.) Obviously this is a bug, but my question is - What if I simply ignore the problem, and don't call Dispose, and just drop reference to the SslStream? Presumably the GC will call finalizer, which will then call Dispose(). Will the GC thread also hang? Will it put mono into a bad state? What could possibly go wrong? Possibly related - I observed that when I set TcpClient read & write timeouts, they seem to have no effect. Set to 6 (60sec), wait a few minutes on a Read or Write (actually BeginRead/EndRead, or synchronous Write) and nothing happens. Thread just blocks indefinitely or the end method is never called. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re. PR 1501: Mark hot functions in the runtime.
In this pull request[1] I add GCC/Clang’s “__attribute__((hot))” to various hot GC functions. This increases code size a small amount, and makes a very small improvement in performance—see the attached graph. I think actually marking some slow-path/error-handling functions as “__attribute__((cold))” would do more to improve branch prediction in cases where we haven’t marked things as “G_UNLIKELY”. [1]: https://github.com/mono/mono/pull/1501 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Status for PR-1489 - AppSettings File attribute symlink
Hi David, I guess that's a good rationale for the change. Said that, why resolving the symlink is needed as they work transparently when open/closing files? On Fri, Jan 23, 2015 at 4:22 PM, David Curylo wrote: > I got a little feedback from Rodrigo Kumpera on this PR 1489 and > responded, but no more discussion since. I’d like to clear up any issues > and make any necessary changes to get this in. The purpose is to get the > attribute to work properly when using a symlink to the > application’s .config file, which I do so that I can keep userland > applications in /usr and configuration in /etc. > > Any more feedback would be welcome, and if this approach is unacceptable, > a suggested alternative would be much appreciated. > > Thanks, > Dave > > On Jan 21, 2015, at 1:08 AM, David Curylo wrote: > > > I have a pull request that’s been complete for a few weeks for adding > symlink support to the path reference in the AppSettings File attribute. > There was a little discussion and seems to be in good shape to merge, but > it’s still waiting. Any status on this one? > > > > https://github.com/mono/mono/pull/1489 > > > > Is something more required? > > > > Thanks, > > Dave > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
