I fear you all misunderstood me. This isn't a case of sabotage or
nasty users, but simply people who do something that they don't
realize can cause a problem.
Our example is quite simple. We have IB network for MPI messages, and
several Ethernet NICs that are dedicated to system-level functions
(e.g., RM communications, file system support). If the users access
the TCP BTL, that code will utilize whatever TCP interface it wants -
including the system-level ones.
The obvious solution is to set the btl_tcp_include param in the
default MCA param file. However, in their ignorance, users will do an
ompi_info, see that param, see the available interfaces, and set it
Your solution won't solve that problem. When users encounter such
obstacles, it is because they are trying to run normally (i.e., using
defaults) and encountering problems - which usually have nothing to do
with constraints imposed in the default params. They talk to each
other and discover that "joe" built his own version of OMPI and was
able to run. Presto - they use his, which doesn't have the same
protections as the production version.
And now they make a mistake that causes a problem.
So this isn't a security issue, nor a problem where somebody is trying
to be stupid or do bad things. It is an inherent "problem" in OMPI
that is caused by our desire to provide "flexibility" and "control" to
the users, as opposed to deliberately restricting "control" to the sys
My intent was not to argue that this isn't worth doing, but simply to
warn you that similar attempts met with failure to fully achieve the
On Sep 4, 2009, at 7:59 AM, Nadia Derbey wrote:
> On Fri, 2009-09-04 at 07:50 -0600, Ralph Castain wrote:
>> Let me point out the obvious since this has plagued us at LANL with
>> regard to this concept. If a user wants to do something different,
>> they have to do is download and build their own copy of OMPI.
>> Amazingly enough, that is exactly what they do. When we build our
>> production versions, we actually "no-build" modules we don't want
>> using (e.g., certain BTL's that use privileged network interfaces) so
>> even MCA params won't let them do something undesirable.
>> No good - they just try until they realize it won't work, then
>> download and build their own version...and merrily hose the system.
>> My point here: this concept can help, but it should in no way be
>> viewed as a solution to the problem you are trying to solve. It is at
>> best a minor obstacle as we made it very simple for a user to
>> circumvent such measures.
>> Which is why I never made the effort to actually implement what was
>> that ticket. It was decided that it really wouldn't help us here, and
>> would only result in further encouraging user-owned builds.
> Let's forget those people who intentionally do bad things: it's true
> that they will always find a way to bypass whatever has been done...
> We are not talking about security here, but there are client sites
> people do not want to care about some mca params values and where
> system-wide params should not be *unintentionally* set to different
>> On Sep 4, 2009, at 12:42 AM, Jeff Squyres wrote:
>>> On Sep 4, 2009, at 8:26 AM, Nadia Derbey wrote:
>>>>> Can the file name ( openmpi-priv-mca-params.conf ) also be
>>>> configurable ?
>>>> No, it isn't, presently, but this can be changed if needed.
>>> If it's configurable, it must be configurable at configure time --
>>> not run time -- otherwise, a user could just give a different
>>> filename at runtime and get around all the "privileged" values.
>>> Jeff Squyres
>>> devel mailing list
>> devel mailing list
> Nadia Derbey <Nadia.Derbey_at_[hidden]>
> devel mailing list