That is good to hear. I have a fairly robust 'plugin' framework that does something similiar to what Alchemi is doing. I actually manage lease-lifetime on the appdomains via the marshal-by-ref controller that gets loaded into each app domain that then loads up the plugin(s)/work units. The appdomain has fairly restricted access to the system. This allows for a 'plugin' or 'package' to hang around until its lease times out. If another work package comes in during the time that the lease is alive it will go ahead a service the request. If the lease expires it will unload the app domain there by reclaiming resources. The way in which I am currently using it is for reporting using Active Reports. It was not designed to be remotable but we worked around that issue by encapsulating the report controller as a remoting service that controls the plugins/reports by loading them in their own app domain and just passing back serialized active report content that is then loaded up by whatever client called it. The manager also handles the caching of the plugins in their own folder and monitors the original non-cached location for updates so that if a report is replaced it will stop using the old version and let it lease expire while at the same time caching and loading the new version which allows us to add and update plugins on the fly without having to restart the system. Would some similiar mechanism be of interest to Alchemi? If so I would be glad to contribute the knowledge that I have gained in my current endeavors.
John
On 2/21/06, Krishna <[EMAIL PROTECTED]> wrote:
Hi John,
Alchemi already does exactly that!
Run each Grid application in a seperate Application domain (on the
executor) created dynamically at runtime;
It has always done that, right from the beginning (It is not just
.Net2.0, even .Net 1.1 gives you good control over AppDomains.). This
way we already do have a simple sandbox on the executor, however
there is a need to enforce proper permissions on the sandbox. Currently
the appdomain created on each Executor gives the app full permissions.
This is actually where improvements need to be made.
Cheers
Krishna.
Jonathan Mitchem wrote:
>John,
>
>Do you have any references, books or web, that discuss .NET 2.0's
>ability to use app domains in that manner?
>
>Jonathan
>
>On 2/21/06, John Sheppard <[EMAIL PROTECTED]> wrote:
>
>
>>Krishna,
>> Another approach you might want to look into is to run each grid app in
>>it's own appdomain and limit the abilities of that app domain. You can lock
>>it down to a specific directory if the executor service is dropping data
>>files to given directories for a grid app. You could lock out app domains
>>from using the System.Net namespaces there by limiting phone home abilities
>>and you can make the executor more resilent by allowing the offending app
>>domain to die upon an unhandled exception rather than bringing down the
>>executor. You could also take advantage of caching grid apps on the client
>>machine where you wouldn't have to push or sip that app if you already have
>>the dlls on your system. .NET 2.0 does a very good job of allowing you set
>>up Sandboxing environs using app domains.
>>
>>John
>>
>>
>>On 2/21/06, Krishna < [EMAIL PROTECTED]> wrote:
>>
>>
>>>Hi Jonathan,
>>>
>>>I guess a simple way to prevent "grid-viruses", would be to use the .NEt
>>>CAS (Code access security)
>>>feature. We will need to implement some code in Alchemi to run user code
>>>under reduced priveleges inside a sand-box kind of environment on
>>>an Executor.
>>>
>>>Cheers
>>>Krishna.
>>>
>>>Jonathan Mitchem wrote:
>>>
>>>
>>>
>>>>I've been thinking about security recently, and started questioning
>>>>the security of a distributed system such as Alchemi.
>>>>
>>>>Is there anything that actually "constrains" the grid environment on a
>>>>machine so that a user doesn't allow some sort of distributed malware
>>>>to damage their machine?
>>>>
>>>>For instance, an application that reads the files on the machine
>>>>hosting the Executor, searches for certain files or filetypes (like,
>>>>password and private key files), and then sends them to a specified
>>>>address. And maybe even proceeds to break their encryption.
>>>>
>>>>Or, an application that creates several threads so that every machine
>>>>has a copy of the required DLLs, which subsequently proceeds to remove
>>>>critical system files from every machine.
>>>>
>>>>Is there anything to prevent such sort of usage? And if not (since
>>>>I'm presuming there isn't), how would we go about preventing such
>>>>damage?
>>>>
>>>>
>>>>Jonathan
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>>
>>>>
>>files
>>
>>
>>>>for problems? Stop! Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>>
>>>>
>>>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>>>
>>>
>>>>_______________________________________________
>>>>Alchemi-developers mailing list
>>>>[email protected]
>>>>
>>>>
>>>>
>>https://lists.sourceforge.net/lists/listinfo/alchemi-developers
>>
>>
>>>>
>>>>
>>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>>>
>>>
>>files
>>
>>
>>>for problems? Stop! Download the new AJAX search engine that makes
>>>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>>>
>>>
>>>
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>>
>>
>>>_______________________________________________
>>>Alchemi-developers mailing list
>>>[email protected]
>>>
>>>
>>>
>>https://lists.sourceforge.net/lists/listinfo/alchemi-developers
>>
>>
>>
>>--
>>Life should NOT be a journey to the grave with the intention of arriving
>>safely in an attractive and well preserved body, but rather to skid in
>>sideways, paddle in one hand, beer in the other, body thoroughly used up,
>>totally worn out and screaming "WOO HOO what a ride!"
>>
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>_______________________________________________
>Alchemi-developers mailing list
> [email protected]
>https://lists.sourceforge.net/lists/listinfo/alchemi-developers
>
>
>
alche
--
Life should NOT be a journey to the grave with the intention of arriving safely in an attractive and well preserved body, but rather to skid in sideways, paddle in one hand, beer in the other, body thoroughly used up, totally worn out and screaming "WOO HOO what a ride!"
