Charles's explanation is a very good one. One piece that may not
have been completely clear about it is that Globus is modular in
nature, and this means that we have intentionally avoided lumping a
whole bunch of separate tasks into a single piece of code. In this
case, the code in question is GRAM. The task that it performs is to
provide a remote interface to local resource management
capabilities. Those capabilities could be a local scheduler or
queueing system (if the target system uses those to implement a local
resource sharing policy), or it could be some kind of execution
environment (either direct execution via fork or managed execution
using a VM or sandboxing tool).
We have intentionally avoiding "bundling" other capabilities into
GRAM. For example, GRAM does not provide a built-in mechanism for
implementing resource management policies, and it does not provide a
built-in mechanism for implementing sophisticated security schemes.
Instead, it provides a very simple default mechanism for each (the
fork jobmanager provides direct execution, the grid-mapfile provides
a simple mapping between a Grid ID and a local account) AND it
provides very nice interfaces that you can use to add your own--more
sophisticated--mechanisms for these tasks.
The jobmanager interface allows you to plug-in your own execution
mechanism, whether that is a different scheduler or queuing system or
a different way to manage jobs (like a VM or a sandbox). Our
expectation is that if you need something other than the basic fork
mechanism or the predefined scheduler interfaces, you will seek out
(or develop) your own execution manager and integrate it with GRAM
via a jobmanager script. For example, there's quite a lot of
interest in the Globus community right now around exploring the use
of VM technology for job execution. (For example, see the Virtual
Workspace service - http://dev.globus.org/wiki/Incubator/
Virtual_Workspaces.) Some of the production Grids in the science
community (OSG, TeraGrid) are also exploring more lightweight
sandboxing tools that do things like limit the memory usage of each
job or restrict access to file spaces on the system.
The grid-mapfile mechanism is pretty simple. All it does is map a
Grid ID (certificate DN) to a local account so that jobs submitted
with a given Grid ID are executed using the corresponding local
account. But it can be combined with other tools to map individual
end user requests to a static or dynamic pool of shared accounts.
The authorization and authentication callout interfaces in WS GRAM
allow you to plug-in your own authorization & authentication
mechanisms to replace the simple grid-mapfile mechanism with more
sophisticated mechanisms. There's quite lot of activity in the
Globus community at present to integrate role-based authorization
with GRAM (see GridShib and VOMS). Combining a pool of shared
accounts with role-based authorization is a powerful model for
provisioning dynamic collaborations without creating individual
accounts for each member of the collaboration, while retaining the
ability to implement and enforce local policies.
The bottom line is that WS GRAM "out of the box" is pretty simple
with respect to both execution management and authentication/
authorization. But its modular design offers the interfaces
necessary to add other Globus or non-Globus tools to provide very
powerful capabilities. Given this flexibility, it's important for
you to decide how you *want* your system to work so that you can
decide which tools, if any, to add to the basic GRAM service to get
things to work exactly how you want.
-- Lee
On Jun 15, 2007, at 8:40 AM, Charles Bacon wrote:
It comes down to trust, right? There are some questions to answer:
1) Do you know who bob is?
2) Do you trust bob?
And for 2, what exactly do you trust bob to do? If you gave bob
access to the globus user's account, would he do something he
shouldn't do? This gets harder when you also want to add alice.
Do you trust bob and alice to both use the account how they're
supposed to, and not to interfere with each other?
Many people find the answer to "do I trust bob to use a shared
account" to be no. For this reason, most sites will only map bob's
DN to an account that bob already owns. Other people decide that
it's okay for bob not to have an account of his own, and there are
various technical solutions to the problem.
One solution to the problem is to create a pool of anonymous
accounts, and map incoming DNs you trust to the random pool.
Another solution might be to start each new job inside a virtual
machine sandbox to isolate it from other users and the real system
underneath.
So the answer is that you can do with the tools whatever makes you
comfortable as a system owner. :-)
Charles
