Subject: Re: mpi-context: security issue

From: L J Clarke <[email-masked]>
Date: Thu, 1 Jul 93 12:05:41 BST

Hi Jim

another day - another mpi-context email session :-)

So we agree on one thing, at least, which is that the exposure of
context leads to a security issue which concerns you. 

I am sure that we can write a draft which adresses this security concern
for the case of intra-group communication and does not omit intra-group
communication.  Is there sufficient demand for the draft to have this
property? I can see that you would like this, Jim.  What about the rest
of the MPI committee.  PLEASE ADVISE. 

> > 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.

I guess the draft allows people to do that but the rule would imply that
they did not use more than one such binding.  In fact we could allow the
multiple binding but the the rule would be perversely complicated to
state.  Hmm, your making a comment on the draft, which is fair enough. 
Personally, I don't see much value in being able to have the multiple
bindings, so we agree somewhere around about here as well, as it
happens. 

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

Again I am sure that we can write a draft which has this property, if
this is what the majority of MPI would like to see.  PLEASE ADVISE. 

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

Yup, this is tricky.  I am still thinking about it, and going around in
circles. I see two possible different requirements:

1.  A desire to allow the programmer to have MPI collective
communications work in any group-context with the user allowed to have
point-to-point communications dangling over the collective call. 

2.  A desire to allow the programmer to write libraries which enjoy the
same protection from the user as the MPI collective communications. 

Point 1.  seems probably not too difficult to manage if we recognise
that the collective communication "library" is privileged in being part
of MPI, whereas the user library is not so privileged.  Point 2.  does
seem more difficult. 

I think your comments have been valuable in a sort of sanity check mode
sense.  Perhaps you would like to make a suggestion regarding the
collective communications.  I, for one, would very much appreciate that. 

Best Wishes
Lyndon

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

---

From: [email-masked] (Al Geist)
Date: Thu, 1 Jul 93 13:39:58 EDT

>I am sure that we can write a draft which has this property, if

I vote with Jim's suggestions.

Al Geist