Erroneous “Insecure world writable dir foo in PATH

2020-03-27 04:14发布

问题:

When I run a ruby script, it gives me this:

[nathanb@nathanb-box ~] myscript .
/u/nathanb/bin/myscript:173: warning: Insecure world writable dir /usr/software/test/bin in PATH, mode 043777
/u/nathanb/bin/myscript:74: warning: Insecure world writable dir /usr/software/test/bin in PATH, mode 043777
/u/nathanb/bin/myscript:79: warning: Insecure world writable dir /usr/software/test/bin in PATH, mode 043777

This message is erroneous, because /usr/software is mounted read-only:

software:/vol/software/  on  /usr/software             type  nfs         (ro,noatime,intr,rsize=32768,wsize=32768,timeo=600,nolock,addr=10.60.132.45,nfsvers=3,proto=tcp,mountproto=udp)

And I can verify this:

nathanb@nathanb-box /usr/software/test/bin] touch foo
touch: cannot touch `foo': Read-only file system

I believe my mount point has the correct permissions:

[nathanb@nathanb-box /usr] ls -ld /usr/software
drwxr-xr-x 27 root root 4096 2010-09-10 17:12 /usr/software

So two questions:

  • Could this legitimately be considered a bug in Ruby?
  • How do I shut this up? Is there a way to disable only this specific warning?

回答1:

You could shut off all warnings with

> ruby -W0 ...

But that may hide other issues. and you did say you want only that specific warning hidden, and I don't think there is a way to do it other than fix the issue, which I think is due to the NFS mount not properly relaying the actual mask. I see this when I mount a non-linux server on linux with NFS.

Like a snao server or something that does not support unix style attributes.

Also as the error is reporting that it doesn't like the world writable directory in the path, could you remove it from the path, and use a prefix to access anything in that directory?

EDIT... Another idea is to filter the output of your ruby script with something like...

> ruby ... | egrep -v "warning: Insecure world writable dir"

That would print any output other (the -v) than the specific warning.

However the warning is a security warning, it is a bad idea to have a world writable directory in your path as anyone can put a malicious script or executable in there. And it is equally bad to have a mounted bin directory especially one you have no control over in your PATH. In this case the issue has nothing to do with whether the directory is writable or not, it is the fact there is a foreign directory in your PATH.

Good practices would dictate that you take that mounted directory out of your PATH and the warning will go away. If you need to execute something that is in that directory, then explicitly provide the full path to the script or executable.

This is not really a Ruby issue but a security issue.



回答2:

We had this situation at work, and although it would be nice to just fix the permissions, that wasn't possible in our environment. Instead, I created the following wrapper script for ruby that suppresses the error.

#!/bin/bash
(ruby.orig "$@" 3>&1 1>&2 2>&3 | grep -v 'Insecure world writable dir'; exit ${PIPESTATUS[0]}) 3>&1 1>&2 2>&3

Just rename the ruby executable to ruby.orig and drop this script into the ruby bin directory in it's place.

See this excellent explanation for how this works.


Another fix for this issue (which avoids the wrapper script) is to compile Ruby with CPPFLAGS="-D ENABLE_PATH_CHECK=0" set when you run ./configure.



回答3:

You can write a method that will suppress the warnings

def suppress_warnings
  original_verbosity = $VERBOSE
  $VERBOSE = nil
  result = yield
  $VERBOSE = original_verbosity
  return result
end

In irb

irb(main):001:0> def suppress_warnings
irb(main):002:1>   original_verbosity = $VERBOSE
irb(main):003:1>   $VERBOSE = nil
irb(main):004:1>   result = yield
irb(main):005:1>   $VERBOSE = original_verbosity
irb(main):006:1>   return result
irb(main):007:1> end
=> nil
irb(main):008:0> Y = :foo
=> :foo
irb(main):009:0> Y = :bar
(irb):9: warning: already initialized constant Y
=> :bar
irb(main):010:0> suppress_warnings { Y = :foo }
=> :foo
irb(main):011:0> 

Of course, you'll have to know where the warnings is coming from and wrap it in a method.