5

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?
Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
Nathan
  • 1,218
  • 3
  • 19
  • 35

3 Answers3

12

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.

Connor McKay
  • 580
  • 7
  • 13
  • 1
    Using `CPPFLAGS="-DENABLE_PATH_CHECK=0"` is a nice way to suppress this warning, thank you. – eregon Feb 02 '20 at 12:11
2

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.

Jim Morris
  • 2,870
  • 24
  • 15
  • Based on the additional info that the `ls -l` produces 0777 then it is not a bug in Ruby, as Ruby is seeing the directory as world writable. Setting the NFS mount to readonly won't change the attribute. – Jim Morris Apr 18 '11 at 21:25
  • @Jim: OK, but the directory isn't writable, even though the permissions might indicate that it is. Seems like ruby should check to see if the filesystem is readonly before issuing spurious warnings. – Nathan Apr 18 '11 at 21:41
  • That is a matter of opinion :) if ls -l shows 0777 then how is Ruby to know any different? Does that mean ls -l should also look at the mount point and change any file it finds to -w instead of +w? Basically the file attributes or permissions is what all programs go on, I have never seen any program take into account the RO status of a mount point. – Jim Morris Apr 18 '11 at 22:11
  • Are there any options I can put in the fstab to change the umask on /usr/software? I tried using mode= and umask=, but mount doesn't accept either of those as options when the fs type is nfs. – Nathan Apr 18 '11 at 22:13
  • I couldn't see any relevant options in mount(8) or nfs(5), except maybe the cache options. It is possible if you turn on the cache then set the permissions locally (if it lets you do that), then the local host will see the locally set permissions and not the remote permissions. I can do this on my Snap server where the owner and permissions are always wrong as it doesn't support them, but it only lasts as long as the mount point does. – Jim Morris Apr 18 '11 at 22:22
  • Maybe "good practices" dictate that I should remove the mount from my PATH, but that mount contains the binaries maintained by corporate engineering support which I use to do my job. The directory is read-only for everyone but a few select administrators. Removing it from my PATH and specifying the absolute path to the binary each time, while possibly conforming to the letter of security best-practices, would be brain-dead. – Nathan Apr 19 '11 at 14:03
  • That makes sense, so the bottom line is I don't think you can stop the error. If you are using the ruby system command it may come from that so you could try an alternative using the fully qualified path name in the ruby script only. Or filter out the message by running in a script that uses the egrep suggestion in my answer. – Jim Morris Apr 19 '11 at 18:21
  • 9
    I don't think it's fair to just say "Good practices would dictate that you take that mounted directory out of your PATH and the warning will go away." I'm maintaining a ruby-based tool that is used by hundreds of developers. It's not my job, nor is it ruby's job, to be their policy enforcer for permissions on their path directories. And as you say, -W0 masks other, more pressing problems that have nothing to do with sloppy permissions behaviors. There ought to be a more targeted solution to this unwanted message. – Br.Bill Sep 30 '11 at 00:18
1

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.

Bam
  • 153
  • 13