Subject: mpi-context: security issue

From: L J Clarke <[email-masked]>
Date: Wed, 30 Jun 93 18:17:36 BST

Dear Jim

The only way I can see of addressing the security issue which concerns
you is to avoid exposing context in MPI.  The particulars of how context
is allocated seems to be neither here nor there. 

Imagine we make what appears to be a weak rule: that the user is only
allowed to bind a context C to a group G in some process P if P has
allocated C and P is a member of G.  This cannot provide the security
your desire.  If P is also a member of some group H then P could
allocate C in H and then bind C to G while the other members of H bind C
to H. 

Imagine we make what appears to be a strong rule: that the user is only
allowed to bind a context C to a group G in some process P if P has
allocated C within the G (by implication P is a member of G).  This
makes it pointless to expose context since the only thing the user can
do is bind it to the group used to allocate it.  Further, if an
implementation was to check that the user obeyed the rule, then it would
have to remember the association between C and G so they are already
bound. 

So I came to the conclusion that the security issue which concerns you
arises directly from the exposed context.  It allows the programmer to
write programs which work as well as programs which do not work --- just
a wee bit like C and Fortran on that score.  Seriously though there is a
philosophical issue whether user interfaces should or should not permit
the user to write incorrect programs.  I sympathise with the enforcement
approach but generally prefer the permissive approach if there is a
reason for it.  I gather that you do not see enough of a reason for MPI
to take the permissive approach in respect of context.  I see this as
being so that we can set up inter-group communication within the same
framework as used to set up intra-group communication. 

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: James Cownie <[email-masked]>
Date: Thu, 1 Jul 1993 11:42:14 +0100

> arises directly from the exposed context.  
I agree this is where the problem arises. As soon as the user can
manage contexts they don't give us security.

> It allows the programmer to write programs which work as well as
> programs which do not work --- just a wee bit like C and Fortran on
> that score.  Seriously though there is a philosophical issue whether
> user interfaces should or should not permit the user to write
> incorrect programs.  I sympathise with the enforcement approach but
> generally prefer the permissive approach if there is a reason for it.
> I gather that you do not see enough of a reason for MPI to take the
> permissive approach in respect of context.  

Exactly. I have no objection to languages which let you do what you
want (after all I use C !), and prefer a sharp kitchen knife to cut
things with. However this doesn't imply that I want to use a sharp
knife to eat my meals with. Tools need to be designed with enough
power to handle the application they're intended for. I think we're
removing all of the safety interlocks from a dangerous tool so that we
can achieve an objective that may be achievable without doing this by
giving a specific contained technique. 

It's like the person who hacked a command like "talk" into an
operating system by adding a system call to let any user write to
arbitrary parts of another process' address space. Sure it works, but
it's more than is needed and has other large implications.

> I see this as being so
> that we can set up inter-group communication within the same framework
> as used to set up intra-group communication.
Maybe, but I need to do so many different things anyway to set up the
two different classes of communicator why not be explicit about it,
and preserve some safety too.

> How we avoid the back-translation which you discussed, is as follows... 
Yup this works fine for the sort of communicators I'd like us to be
able to construct. It falls over as soon as people exploit the ability
to bind the same context to different groups. Since that is allowed in
the current draft this soilution is incompatible with the current
draft.

As you know by now I'd like to ENFORCE the (reasonable) limitations by
construction, in which case this solution is fine.

(I'm still waiting for the collective example though !)

-- Jim
James Cownie 
Meiko Limited			Meiko Inc.
650 Aztec West			Reservoir Place
Bristol BS12 4SD		1601 Trapelo Road
England				Waltham
				MA 02154

Phone : +44 454 616171		+1 617 890 7676
FAX   : +44 454 618188		+1 617 890 5042
E-Mail: [email-masked]   or    [email-masked]