3

update: the error only occurs when logged into R from within emacs

what works:

When I ssh into a remote server and run

$ ./foo.rb

from the bash shell, it works. Furthermore, if I launch R and execute $ R

system('./foo.rb')

I am in a group with permission to read/write/execute the file. File permissions are -rwxrwx---

what doesn't work:

Launch emacs and start an R session:

  • M-x R
  • ssh-myserver:.

    system('./foo.rb')

I get the following error:

ruby: Permission denied -- foo.rb (LoadError)

why is this? Is there a way to work around this?

I can not find any information from ?system or ?system2


Here is the output from sessionInfo()

> sessionInfo()
R version 2.12.2 (2011-02-25)
Platform: x86_64-redhat-linux-gnu (64-bit)

locale:
[1] C

attached base packages:
[1] grid      stats     graphics  grDevices utils     datasets  methods  
[8] base     

other attached packages:
 [1] PECAn_0.1.1      xtable_1.5-6     gridExtra_0.7    RMySQL_0.7-5    
 [5] DBI_0.2-5        ggplot2_0.8.9    proto_0.3-8      reshape_0.8.3   
 [9] plyr_1.6         rjags_2.2.0-2    coda_0.13-5      lattice_0.19-17 
[13] randtoolbox_1.09 rngWELL_0.9      MASS_7.3-11      XML_3.2-0       

loaded via a namespace (and not attached):
[1] digest_0.4.2
Warning message:
'DESCRIPTION' file has 'Encoding' field and re-encoding is not possible 

output of 'id' and 'env' from ssh and emacs, per comment by @sarnold (changed user names, group names, and ip addresses)

1. server

1.1 'id'

 uid=1668(dleb) gid=1668(dleb) groups=117(ebusers),159(lab_admin),166(lab),1340(pal_web),1668(dleb)

1.2 'env'

LC_PAPER=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
SHELL=/usr/local/bin/system-specific
KDE_NO_IPV6=1
SSH_CLIENT=888.888.888.88 51857 22
NCARG_FONTCAPS=/usr/lib64/ncarg/fontcaps
LC_NUMERIC=en_US.UTF-8
USER=dleb
LS_COLORS=
LC_TELEPHONE=en_US.UTF-8
KDEDIR=/usr
NCARG_GRAPHCAPS=/usr/lib64/ncarg/graphcaps
MAIL=/var/mail/dleb
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/dell/srvadmin/bin
LC_IDENTIFICATION=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
R_LIBS=/home/a-m/dleb/lib/R
PWD=/home/dleb
NCARG_ROOT=/usr
KDE_IS_PRELINKED=1
LANG=en_US.UTF-8
NCARG_DATABASE=/usr/lib64/ncarg/database
MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
LOADEDMODULES=
LC_MEASUREMENT=en_US.UTF-8
NCARG_LIB=/usr/lib64/ncarg
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
NCARG_NCARG=/usr/share/ncarg
SHLVL=1
HOME=/home/a-m/dleb
LOGNAME=dleb
CVS_RSH=ssh
SSH_CONNECTION=888.888.888.88 51857 999.999.999.99 22
LC_CTYPE=en_US.UTF-8
MODULESHOME=/usr/share/Modules
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=localhost:15.0
LC_TIME=en_US.UTF-8
G_BROKEN_FILENAMES=1
LC_NAME=en_US.UTF-8
_=/bin/env

emacs/ess R session

2.1 system('id')

uid=1668(dleb) gid=1668(dleb) groups=117(ebusers),159(lab_admin),166(lab),1340(pal_web),1668(dleb)

2.2 system('env')

LN_S=ln -s
R_TEXI2DVICMD=/usr/bin/texi2dvi
LC_PAPER=en_US.UTF-8
SED=/bin/sed
LC_ADDRESS=en_US.UTF-8
R_PDFVIEWER=/usr/bin/xdg-open
LC_MONETARY=en_US.UTF-8
HOSTNAME=ebi-forecast
R_INCLUDE_DIR=/usr/include/R
R_PRINTCMD=lpr
SHELL=/usr/local/bin/system-specific
TERM=dumb
AWK=gawk
HISTSIZE=1
R_RD4DVI=ae
SSH_CLIENT=888.888.888.88 51159 22
KDE_NO_IPV6=1
R_RD4PDF=times,hyper
R_PAPERSIZE=a4
NCARG_FONTCAPS=/usr/lib64/ncarg/fontcaps
PERL=/usr/bin/perl
LC_NUMERIC=en_US.UTF-8
SSH_TTY=/dev/pts/14
LC_ALL=C
EMACS=t
USER=dleb
LC_TELEPHONE=en_US.UTF-8
LS_COLORS=
LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib
TAR=/bin/gtar
ENV=
R_ZIPCMD=/usr/bin/zip
KDEDIR=/usr
PAGER=/usr/bin/less
NCARG_GRAPHCAPS=/usr/lib64/ncarg/graphcaps
R_GZIPCMD=/usr/bin/gzip
PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
LC_COLLATE=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
EGREP=/bin/grep -E
PWD=/home/a-m/dleb/pecan
INPUTRC=/etc/inputrc
R_LIBS=/home/a-m/dleb/lib/R
NCARG_ROOT=/usr
R_SHARE_DIR=/usr/share/R
WHICH=/usr/bin/which
EDITOR=vi
LANG=en_US.UTF-8
KDE_IS_PRELINKED=1
R_LIBS_SITE=/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib64/R/library:/usr/share/R/library
M    ODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
NCARG_DATABASE=/usr/lib64/ncarg/database
LC_MEASUREMENT=en_US.UTF-8
LOADEDMODULES=
PS3=
R_BROWSER=/usr/bin/xdg-open
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
NCARG_LIB=/usr/lib64/ncarg
HOME=/home/a-m/dleb
SHLVL=1
NCARG_NCARG=/usr/share/ncarg
R_ARCH=
TR=/usr/bin/tr
MAKE=make
R_UNZIPCMD=/usr/bin/unzip
LOGNAME=dleb
CVS_RSH=ssh
LC_CTYPE=en_US.UTF-8
SSH_CONNECTION=888.888.888.88 51159 999.999.999.99 22
R_BZIPCMD=/usr/bin/bzip2
MODULESHOME=/usr/share/Modules
LESSOPEN=|/usr/bin/lesspipe.sh %s
PROMPT_COMMAND=
R_HOME=/usr/lib64/R
DISPLAY=localhost:22.0
R_PLATFORM=x86_64-redhat-linux-gnu
INSIDE_EMACS=23.2.1,tramp:2.1.18-23.2
R_LIBS_USER=~/R/x86_64-redhat-linux-gnu-library/2.12
LC_TIME=en_US.UTF-8
R_DOC_DIR=/usr/share/doc/R-2.12.2
R_SESSION_TMPDIR=/tmp/RtmpqA6bpJ
HISTFILE=/home/a-m/dleb/.tramp_history
G_BROKEN_FILENAMES=1
LC_NAME=en_US.UTF-8
_=/bin/env
David LeBauer
  • 31,011
  • 31
  • 115
  • 189
  • Obvious question: is the file executable by everyone? I.e. what are the exact permissions? – Joshua Ulrich Oct 21 '11 at 15:04
  • permissions are `-rwxrwx---`, I have updated the question – David LeBauer Oct 21 '11 at 15:10
  • Okay, so it's not executable by everyone. Does it work if you set the file permissions to `-rwxrwx--x`? If so, the user running R is probably not in the group that has execute permission. – Joshua Ulrich Oct 21 '11 at 15:17
  • What does foo.rb do? A simple hello world in ruby works for me from system, even with those permissions. I suspect the ruby is doing something, so the answer is going to be specific to whatever is going on in there... – Spacedman Oct 21 '11 at 15:22
  • @Joshua If I launch R, then I should be the user running R, right? – David LeBauer Oct 21 '11 at 15:22
  • For one thing, system("./foo.rb") has to read the file to even work out that is *is* ruby (assuming there's a #! path in it). Something else is afoot here. – Spacedman Oct 21 '11 at 15:23
  • @Spacedman all that it does is open and manipulate a text file that has the same permissions. Note that I am not the owner of the script. If copy the file to my home directory, so that I am both the owner and group, it works. – David LeBauer Oct 21 '11 at 15:26
  • @David: it depends on how your system is set up. You (or someone else) could be the owner of `foo.rb` and you could be running R via a different user. This is likely a permission issue and has nothing to do with R, specifically. – Joshua Ulrich Oct 21 '11 at 15:27
  • Try it from python: import os [newline] os.system("./foo.rb") [newline] – Spacedman Oct 21 '11 at 15:31
  • @JoshuaUlrich is there a way that I can find out? `system('echo $USER')`, returns my user name. I can ask the system admin, but I am not sure what exactly to ask - or how to work around it. The system is a Red Hat cluster. – David LeBauer Oct 21 '11 at 15:31
  • @David See answer below. Your error is coming from ruby, NOT the shell, so the permissions on foo.rb are fine. It's some other file that has the problem... – John Colby Oct 21 '11 at 15:35
  • 1
    Also, try system("id") to see what id it thinks you are. Maybe someone installed R to run setuid someone else... Or run system("sh") and try your ruby from that shell – Spacedman Oct 21 '11 at 15:35
  • @Spacedman thanks for the tips. I can not reproduce the error now. – David LeBauer Oct 21 '11 at 15:50
  • @Spacedman Okay, the reason that I could not reproduce the error was because it is only occurring from within emacs. – David LeBauer Oct 21 '11 at 16:06
  • Compare the results of the `id` command from the shell and from inside emacs (`M-! id RET`). – zwol Oct 21 '11 at 16:23
  • @Zack from within the R buffer, they are the same (different if I go to a buffer with a local file open) – David LeBauer Oct 21 '11 at 16:35
  • What does `ssh-myserver` do? It works for me just fine from within emacs, but I'm not running that command (or whatever it is). – Aaron left Stack Overflow Oct 21 '11 at 18:21
  • @aaron it opens up an r session on the server – David LeBauer Oct 21 '11 at 18:23
  • @zack the difference is that the R session is open on the server and the local buffer is on my local machine. It is the same as the difference between issuing `id` and `ssh myserver "id"` – David LeBauer Oct 21 '11 at 18:24
  • @David, can you [edit] your post to include the output of `id` and `env` when run via `ssh` directly and with `emacs`? `ssh myserver id`, `ssh myserver env`; and then `emacs`, `M-x R`, `ssh myserver id`, `emacs`, `M-x R`, `ssh myserver env`. – sarnold Oct 22 '11 at 06:03
  • @sarnold I have put the output of 'id' and 'env' in the post. 'id' is the same, 'env' is not. – David LeBauer Oct 24 '11 at 14:31
  • this question seems to report a similar issue when running on a localhost: http://stackoverflow.com/q/11005478/513006 – Abe Jun 13 '12 at 14:20

2 Answers2

3

Assuming you started up R as the same user, you do. You error is not coming from a permissions problem for foo.rb, however, or else your shell would be giving the error. (i.e. sh: ./test.rb: Permission denied; see example below). Here, ruby itself is giving the error. Without knowing exactly what is in your foo.rb, I would suggest digging in there to see what it is trying to load/source, and checking the permissions on those.

#!/usr/bin/env ruby

puts 'Hello world'

Now in R....

> system('ls -l test.rb')
-rw-r--r--  1 jcolby  staff  40 Oct 21 08:23 test.rb
> system('./test.rb')
sh: ./test.rb: Permission denied
> system('chmod a+x test.rb')
> system('./test.rb')
Hello world
John Colby
  • 22,169
  • 4
  • 57
  • 69
  • Thanks for your answer. I am not sure why, but this error is only occurring from within emacs. Still your test script works fine (where I am both owner and group). – David LeBauer Oct 21 '11 at 16:07
  • Ahh good to rule out some things at least. I'm don't know emacs, but I'm sure someone who does will pop in with ideas. Maybe tweak your title to attract more emacs attention? – John Colby Oct 21 '11 at 16:15
2

I presume the M ODULEPATH in the Emacs-derived output is simply a copy and paste typo.

The differences between the two env outputs is much greater than I expected; I've selected the ones that look slightly suspicious to me:

$ diff -u works fails
--- works   2011-10-24 15:04:02.000000000 -0700
+++ fails   2011-10-24 15:12:36.000000000 -0700
...
+LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib
...
-PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/opt/dell/srvadmin/bin
-PWD=/home/dleb
...
+PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin
...
+PWD=/home/a-m/dleb/pecan
...

In the emacs-derived session, your LD_LIBRARY_PATH environment variable may be changing specifics of which dynamically linked libraries are being used when executing ruby. If you ssh in to your server and execute your foo.rb with the changed LD_LIBRARY_PATH, does it work or fail?

LD_LIBRARY_PATH=/usr/lib64/R/lib:/usr/local/lib64:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib ./foo.rb

The PATH environment variable between the two sessions is different; perhaps you have permission to execute /usr/local/bin/ruby (or the libraries in /usr/local/lib/ruby/) but not /usr/bin/ruby (or the libraries in /usr/lib/ruby/). Does your script use #!env ruby or does it use #!/usr/bin/ruby (or some other fixed path)?

Your pwd in one instance is /home/dleb, the other /home/a-m/dleb/pecan -- but HOME is set to /home/a-m/dleb on both systems. Is /home/dleb a symbolic link or does it actually exist separate from /home/a-m/dleb? (This really is grasping at straws -- I don't think this is it, but this problem is baffling.)

One last thing to consider: is your server confined with a tool such as AppArmor, SELinux, TOMOYO, or SMACK? Any of these mandatory access control tools can prevent an application from writing in specific locations, perhaps they aren't yet configured for your site. Check dmesg(1) output to see if there are any rejection messages, most or all these tools log to dmesg(1) if auditd(8) isn't running.

sarnold
  • 102,305
  • 22
  • 181
  • 238