Understood. So, let's say that we're only implementing a hurdle to
discourage users from doing things wrong. I guess the efficiency of this
will reside in the message displayed to the user ("You are about to break
the entire machine and you will be fined if you try to circumvent this in
Maybe the warning message should be set by administrators
($OMPI/.../no-override.txt). It would certainly be more efficient :)
On Fri, 4 Sep 2009, Ralph Castain wrote:
> 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
> 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 improperly.
> 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 admins.
> 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 desired goal.
> 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, all
>>> 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 them
>>> 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 in
>>> 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 where
>> people do not want to care about some mca params values and where those
>> 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
> devel mailing list