Thanks for the clarification. Looks like you've done some very good work by adding the security. I am glad that you can enable/disable it.
The more I think about this, the more I wonder if my application would be more efficient if I did my simulations with a GJob. I think i'll try to work on that and see if I can get it working. The only thing I can think of is that I need a custom GJob that lets you specify not only the input and output file collections, but also _multiple_ commands to be run, sequentially. This shouldn't be too hard and I can send you my code if you'd like to add it to the project.
I think your explanation has also shed some light on my earlier posts to the list about serializing custom exceptions.
You said "These include: - creating a directory for the app, and an appdomain with its base directory set to the app dir"
That makes sense, and I've watched this directory get created and all of the modules in the GApplication manifest get dumped to disk here. The thing was, I think that when my GThread threw a custom exception, defined in one of these modules, it got transferred to the executor appdomain which had its base directory specified as C:\Program Files\Alchemi\Executor\. So when it tried to deserialize it, the executor couldn't find the DLL with the correct custom exception type because that DLL is in C:\Program Files\Alchemi\Executor\dat\[blah]\[blah] (which may or may not even still be around). This means that if our GThreads throw custom exceptions, that the DLL that contains them must reside in the executor appdomain's base directory. Do you think this is the case or have I misdiagnosed the problem? My tests today seemed to confirm this but there could be another explanation.
The end result is that I have 2 options: 1) manually install the DLL into the executor base directory (this is a big deployment issue since I am constantly updating my libraries) or 2) don't throw custom exceptions.
By the way, thanks again for such a great framework. Even though I've been having problems with it (they are probably my fault) it has already saved me enough computational hours to be worth its weight in gold.
Thanks,
-Matt
On 11/10/06, Krishna <[EMAIL PROTECTED]> wrote:
Hi Matt,
v1.0.6 was released a few weeks ago and I (think I) did send out a
message on alchemi users and developers lists and also notified those
that were watching the release as well.
1.0.6 does some bug fixing, but it seems to have added some bugs of its
own. Especially with GJobs and the GUIs.
With regards to security, it is turned off by default. Even if it were
enabled, GJobs will not work with this model, since the security
sandboxing we apply to the isolated appDomain in which the
thread/job runs will need 'unmanaged' code permissions - which defeat
the purpose of sandboxing the way it is done now.
Basically, what you can see in the code is:
1. when a Gthread comes in, the Executor checks if some initialisation
steps have been done for the GApp which the thread belongs to.
These include:
- creating a directory for the app, and an appdomain with its base
directory set to the app dir
- applying a default security policy to this appdomain
2. Once that is done, each thread gets its own directory (to enable more
that one thread running at the same time on the same executor).
So, effectively the 'working dir' for the thread will be its own dir
under the app dir. (which itself is in the
[ADD_DATA_DIR]\Alchemi\Executor\dat\[AppId]).
APP_DATA_DIR is the application data dir for the user who is running the
Alchemi Executor
so, for the LocalService user, it is something like :
C:\Documents and Settings\LocalService\Application Data\Alchemi\Executor\dat
So, security implications at the moment :
- none by default - since it is not enabled.
- GJobs or any threads which call into unmanaged code will not run if
security is enabled (this can be done through the config file, I will
fix the GUI to have that option properly too...)
To answer your questions:
---So....will I run into security problems if I upgrade to 1.0.6?
- by default - NO.
--- Can the new GThreads read, write, and delete files on the executor's
disk?
- if security is enabled, GThreads will only be able to write to/delete
files in its current directory only. I think threads can read files
anywhere the 'user running Executor' has read permissions. (Pls let me
know if that isn't the case)
--- If not, is there a specific filesystem location (a local store,
perhaps) that the GThread can read and write to?
- Yes, the working Dir of the GThread. You can access that property from
the GThread object.
These things are unlikely to change too much in the short term. So, I am
not surely how useful this sandboxing feature will be. If it is to
restrictive, I see lots of people just turning it off.
So - need to test and evaluate, and some feedback will be useful.
I would suggest you wait until a week or two, which is when I plan to
release v.1.0.7 (which fixes the most obvious bugs in v.1.0.6)
Cheers
Krishna
Matt Valerio wrote:
> Hello everyone,
>
> I'm currently running Alchemi 1.0.5 on my grid and have been wondering
> if upgrading to 1.0.6 would be a good move.
>
> I know there had been some discussion on the list a few months ago
> about how security will be handled in Alchemi. I see (just today,
> would have been nice to have an announcement or something) that 1.0.6
> is out now. Cool.
>
> Currently my GThreads execute by spawning off a
> System.Diagnostics.Process class to execute a certain executable that
> runs my simulations. Because my code is a mixture of C# file I/O and
> F*RTRAN-compiled-into-an-exe, the GJob was suited for the job and I
> decided to use a GThread that spawned a Process.
>
> So....will I run into security problems if I upgrade to 1.0.6?
>
> Can the new GThreads read, write, and delete files on the executor's disk?
> If not, is there a specific filesystem location (a local store,
> perhaps) that the GThread can read and write to?
>
> From browsing around in the CVS in the function CreateSandboxDomain
> http://alchemi.cvs.sourceforge.net/alchemi/alchemi-devel/src/Alchemi.Executor/ExecutorWorker.cs?revision=1.1&view=markup
> <http://alchemi.cvs.sourceforge.net/alchemi/alchemi-devel/src/Alchemi.Executor/ExecutorWorker.cs?revision=1.1&view=markup >
> it seems that the directory is read-only. :(
>
> Can someone comment on the security implications of the 1.0.6 release?
>
> Thanks!
> -Matt
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ alchemi-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-users
