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
any way").
Maybe the warning message should be set by administrators
($OMPI/.../no-override.txt). It would certainly be more efficient :)
Sylvain
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
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 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.
Ralph,
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
values.
Regards,
Nadia
:-(
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
jsquy...@cisco.com
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Nadia Derbey <nadia.der...@bull.net>
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
