Hello All,
I have come up with a fix/workaround which turns off the “insecure world
writable” warning message.
In my code, I pass a string (exec_str) to exec:
exec_str = "./foo.pl test"
exec(exec_str)
Depending on my PATH, this can point out any number of world-writable
directories on my network.
If I change the above so I’m just adding a CR to the end of exec_str, I
now do not see the warning message any longer:
exec_str = "./foo.pl test\n"
exec(exec_str)
Anyone have an idea why this works?
Thanks,
-Sean
Sean H. wrote:
Depending on my PATH, this can point out any number of world-writable
directories on my network.
If I change the above so I’m just adding a CR to the end of exec_str, I
now do not see the warning message any longer:
exec_str = "./foo.pl test\n"
exec(exec_str)
Anyone have an idea why this works?
Heck of a workaround. Thanks. I look forward to
explanations as to why it works.
I’ve been using this:
exec_str = “eval ‘’; …”
The initial eval also stops the insecure writable
message.
There’s no way to modify the environment, either.
Access ENV. causes the message to appear
before I even try to execute anything in a subshell.
That message is one heckofa mystery, to be sure.
“S” == Sean H. [email protected] writes:
S> exec_str = “./foo.pl test\n”
S> exec(exec_str)
S> Anyone have an idea why this works?
When ruby find some special characters (like \n;[]{} …) in the
string, it
call the shell (/bin/sh -c) rather than trying to exec directly the
program. In this case it don’t test the variable PATH
Guy Decoux
Ok, I understand the reason this works the way it does - Ruby wants the
shell to handle any special characters that may result in
substitutions/matching, etc. That makes sense. But is there an “official
workaround” for this problem? And if not, can I rest well at night with
my ‘\n’ workaround in my companys stable source tree? It’s just a
warning message now, but in the future, I can’t really forsee any
problems with putting a CR at end of exec_str, but…
Thanks,
-Sean
“S” == Sean H. [email protected] writes:
S> substitutions/matching, etc. That makes sense. But is there an
“official
S> workaround” for this problem? And if not, can I rest well at night
with
Yes, correct the problem (i.e. change the permission for the directory)
S> my ‘\n’ workaround in my companys stable source tree? It’s just a
S> warning message now, but in the future, I can’t really forsee any
it’s a warning message with $SAFE = 0, but an error with $SAFE >= 1
svg% ruby -e ‘exec(“ls”)’
-e:1: warning: Insecure world writable dir /home/ts/XXX/., mode 040777
svg%
svg% ruby -e ‘$SAFE = 1; exec(“ls”)’
-e:1: warning: Insecure world writable dir /home/ts/XXX/., mode 040777
-e:1:in `exec’: Insecure PATH - ls (SecurityError)
from -e:1
svg%
Guy Decoux
As the ts said, setting the $SAFE is a way to ignore the warning.
Or
run the ruby script like this:
ruby -w0 file…
Last we can change the permission of the dictionary.
For example,
drwxr-xr-x 7 abc abc … /home/abc/bin
Let other users can only access the dictionary.
ts wrote:
“S” == Sean H. [email protected] writes:
S> substitutions/matching, etc. That makes sense. But is there an
“official
S> workaround” for this problem? And if not, can I rest well at night
with
Yes, correct the problem (i.e. change the permission for the directory)
S> my ‘\n’ workaround in my companys stable source tree? It’s just a
S> warning message now, but in the future, I can’t really forsee any
it’s a warning message with $SAFE = 0, but an error with $SAFE >= 1
svg% ruby -e ‘exec(“ls”)’
-e:1: warning: Insecure world writable dir /home/ts/XXX/., mode 040777
svg%
svg% ruby -e ‘$SAFE = 1; exec(“ls”)’
-e:1: warning: Insecure world writable dir /home/ts/XXX/., mode 040777
-e:1:in `exec’: Insecure PATH - ls (SecurityError)
from -e:1
svg%
Guy Decoux
there’s tons of threads about this, e.g.
http://www.ruby-forum.com/topic/191771
Search the mailing list for more
Greetz!
2009/9/1 Hugh H. [email protected]
what is the best gui for ruby and where can i find it?