Re: [Rd] R and sun gridengine
Kim Carter wrote: > Hi > > I am looking for assistance with setting up R under Sun grid engine 6 > (6.0-update7). I would like to set up transparent interactive access > to R using either a qlogin or qrsh solution. While it basically works > using either method, I reach the same sticking point. There seems > to be an issue with signalling or something, as R works ok until a > non-R command is typed in - eg "blah" - at which point the remote > session is terminated (note: i am using ssh as an rsh/rlogin replacement). > > If anyone has any suggestions or can point me in the right direction, > it would be greatly appreciated. > > Kim Carter > > > -- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Are you trying something like 'qrsh R' ? Then the reason might be a missing tty and R goes to batch-mode, like: bagheera:~>qrsh tty not a tty but: bagheera:~>qrsh Last login: Fri Mar 24 14:02:47 from bagheera.CeBiTe morpheus:~> tty /dev/pts/3 If you supply a command to qrsh, you will not have a terminal. I think there is no switch to force R into interactive mode,like for example for 'bash -i'. I found: http://www.r-project.org/nocvs/mail/r-help/2002/8927.html but have not checked if it still works. Maybe this helps Michael -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Operator masks in R, restrict set of applicable functions
Hi,
is there a way to restrict the set of admissible functions for an eval()
statement to a possibly 'safe' set, excluding all potentially dangerous
functions like 'system', 'open', etc.(like, for instance, in the 'Safe'
module for Perl)?
The background for this question is, that this would be run in a
CGI-environment. The user should be able to input some R-code (a
function assignment), thereafter the code is parsed, evaluated and the
type of function parameters checked by a call to 'formals'
like in:
> expr <- parse(text='foo <- function(x = numeric()){mean(x)}')
> eval(expr[1])
> formals(foo)
$x
numeric()
of course, this is highly dangerous, given this setting, as one could try
> expr <- parse(text='system("ls");
foo <- function(x = numeric()){mean(x)}') # or more evil things
> eval(expr)
I know I could do something like
> system <- function(...) stop ('This is not allowed!')
but it's rather likely to miss one of the 'bad' functions.
Any ideas would be appreciated.
Regards
Michael Dondrup
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Operator masks in R, restrict set of applicable functions
Thank you very much,
Sorry for bothering again, but how about this:
> assignInNamespace('system',function(...)stop('No system!'),'base')
> system()
Error in system() : No system!
> base::system()
Error in base::system() : No system!
> detach(package:utils) # no way back?
I guess there is a way to circumvent that, too?
Of course, if it works, it's tideous work to do this for all unsafe
functions (of course: file, url, unlink, dyn.load,..., maybe I'm just
too cautious )
I would really like to chroot the R-process, and agree it would be the
best option, but I'm using RSPerl, which loads R.so. Hence, I cannot
restrict R-code more than the web-server(at least I think so). Though
this would be necessary, as the web-server accesses some files that
unsafe code should never even be able to read, including the cgi-scripts.
Thank you again
Michael
Prof Brian Ripley wrote:
> On Mon, 27 Mar 2006, Michael Dondrup wrote:
>
>
>>Hi,
>>is there a way to restrict the set of admissible functions for an eval()
>>statement to a possibly 'safe' set, excluding all potentially dangerous
>>functions like 'system', 'open', etc.(like, for instance, in the 'Safe'
>>module for Perl)?
>
>
> In short, no. (BTW, what is unsafe about 'open'? What are you trying to
> circumvent here? E.g. unlink() might be on your list, as might file().)
>
> The normal approach is to run R in an environment which restricts what the
> user can do: that should be sufficient to avoid unwanted file deletions,
> for example.
>
> One could argue that a lot of these operations should be in a package
> other than base, but much of R is itself written in R and assumes them.
> (I did look into putting system() and file.*() in utils when the current
> organization of packages was made, but at least at the time they were too
> deeply embedded in other functionality.)
>
> One idea would be to evaluate your expression in a strictly controlled
> environment of your own choosing, but there are ways for knowledgeable
> users to circumvent that (see below).
>
>
>>The background for this question is, that this would be run in a
>>CGI-environment. The user should be able to input some R-code (a
>>function assignment), thereafter the code is parsed, evaluated and the
>>type of function parameters checked by a call to 'formals'
>>like in:
>>
>>>expr <- parse(text='foo <- function(x = numeric()){mean(x)}')
>>>eval(expr[1])
>>>formals(foo)
>>
>>$x
>>numeric()
>>
>>of course, this is highly dangerous, given this setting, as one could try
>>
>>>expr <- parse(text='system("ls");
>>
>>foo <- function(x = numeric()){mean(x)}') # or more evil things
>>
>>>eval(expr)
>>
>>I know I could do something like
>>
>>>system <- function(...) stop ('This is not allowed!')
>>
>>but it's rather likely to miss one of the 'bad' functions.
>
>
> But a user can use base::system, and load packages which could contain
> arbitrarily dangerous code (even its own compiled-code version of system).
>
>
>>Any ideas would be appreciated.
>>
>>Regards
>>Michael Dondrup
>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
--
Dipl. Inform. Michael Dondrup
CeBiTec - http://www.cebitec.uni-bielefeld.de/~mdondrup
Bielefeld University, D-33594 Bielefeld, Germany
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R and sun gridengine
Michael Dondrup wrote: > Kim Carter wrote: > >>Hi >> >>I am looking for assistance with setting up R under Sun grid engine 6 >>(6.0-update7). I would like to set up transparent interactive access >>to R using either a qlogin or qrsh solution. While it basically works >>using either method, I reach the same sticking point. There seems >>to be an issue with signalling or something, as R works ok until a >>non-R command is typed in - eg "blah" - at which point the remote >>session is terminated (note: i am using ssh as an rsh/rlogin replacement). >> >>If anyone has any suggestions or can point me in the right direction, >>it would be greatly appreciated. >> >>Kim Carter >> >> >>-- >> >>__ >>R-devel@r-project.org mailing list >>https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > Are you trying something like > 'qrsh R' ? Then the reason might be a missing tty and R goes to > batch-mode, like: > > bagheera:~>qrsh tty > not a tty > > but: > > bagheera:~>qrsh > Last login: Fri Mar 24 14:02:47 from bagheera.CeBiTe > morpheus:~> tty > /dev/pts/3 > > If you supply a command to qrsh, you will not have a terminal. > > I think there is no switch to force R into interactive mode,like for > example for 'bash -i'. I found: > http://www.r-project.org/nocvs/mail/r-help/2002/8927.html > but have not checked if it still works. > > Maybe this helps > Michael > > > > > > > > > -- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Hi, I forgot to add a much simpler solution, so try (something like): >qrsh xterm -e R you might have to adjust your $DISPLAY, in particular, if you are using Sun ray-terminals or better: use the qxterm script (I think it comes wit sge 6, but not sure) -- Dipl. Inform. Michael Dondrup CeBiTec - http://www.cebitec.uni-bielefeld.de/~mdondrup __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] protect/unprotect howto in C code
Hi, Im currently trying to debug a 'error in unprotect: stack imbalance' problem and I am curious about two basic questions on the use of PROTECT and UNPROTECT, which I could not figure out: - which objects have to be protected, namely, if the code is something like: SEXP fun, e; /* get the expression e ... */ fun = eval(e, R_GlobalEnv); /* or like this?: PROTECT(fun = eval(e, R_GlobalEnv)); */ PROTECT(fun = VECTOR_ELT(fun, 1)); /* do more things with fun ... */ does one need to protect the result of a call to 'eval' immediately? And how about R_tryEval? While searching for code examples in the sources, I found both protected evals and fewer non-protected. - Can someone give a hint (or some documents) on a way to simplify debugging such problem in addition to using gdb, please? I thought about temporarily defining macros such as #define DEBUG_Protect(x) PROTECT(x); fprintf(stderr, "Protecting in %s, l: %d\n", __FILE__, __LINE__) #define UNDEBUG_Protect(x) fprintf(stderr, "Unprotecting %d in %s, l:, %d \n", x , __FILE__, __LINE__); UNPROTECT(x); and then replace all calls temporarily in the package source. But there must be a better way... Thank you very much (and my appologies, if this sounds odd to more experineced c programmers ;) ) Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] protect/unprotect howto in C code
Thank you very much, Thomas! Thanks to the explanation, I think I could almost track down that bug. May I, just for clarification, ask a further bunch of questions (sorry). From what you say, did I get it right: - 'error in unprotect: stack imbalance' is only a warning, it will not cause termination, unless R is running as an embedded process (I'm working with RSPerl package in perl here)? - Forgetting to unprotect a value is harmless, and will only provoke these warnings? - If the protect/unprotect is unbalanced within a function call, R will give the warning/error already at the exit of this specific function? - If that is the case, what if I want to return a pointer to a value from a function? Do have to unprotect it anyway, before? btw: I'm working on FreeBSD, I found an experimental port of valgrind, too. Thank you very much again! Michael On Wednesday 17 May 2006 16:55 Thomas Lumley wrote: > On Wed, 17 May 2006, Michael Dondrup wrote: > > Hi, > > > > Im currently trying to debug a 'error in unprotect: stack imbalance' > > problem and I am curious about two basic questions on the use of PROTECT > > and UNPROTECT, which I could not figure out: > > > > - which objects have to be protected, namely, if the code is something > > like: > > > > SEXP fun, e; > > /* get the expression e ... */ > > fun = eval(e, R_GlobalEnv); > > /* or like this?: PROTECT(fun = eval(e, R_GlobalEnv)); */ > > PROTECT(fun = VECTOR_ELT(fun, 1)); > > /* do more things with fun ... */ > > > > does one need to protect the result of a call to 'eval' immediately? And > > how about R_tryEval? > > While searching for code examples in the sources, I found both protected > > evals and fewer non-protected. > > The first rule is that any newly created R object needs to be protected > before the garbage collector runs, and unprotected before exiting the > function and after the last time the garbage collector runs. > > The second rule is that protection applies to the contents of a variable > (the R object) not to the variable. > > The second rule is that protecting an object protects all its elements. > > In the example above > fun = eval(e, R_GlobalEnv); > may create a new object (it might just return a pointer to an existing > function) and so probably needs to be protected. > > On the other hand > fun = VECTOR_ELT(fun, 1); > does not then need protecting. Since fun is protected, its second element > is also protected. > > So > PROTECT(fun = eval(e, R_GlobalEnv)); > fun = VECTOR_ELT(fun, 1); > /* do more stuff with fun */ > UNPROTECT(1); > > If you don't know exactly which functions might return a new object or > trigger the garbage collector it is probably safe to assume that anything > might [this is the advice in 'Writing R Extensiosn']. Unless you are > getting close to the limits of the pointer protection stack (eg in > recursive algorithms), you might be safer writing code like > PROTECT(fun = eval(e, R_GlobalEnv)); > PROTECT(fun = VECTOR_ELT(fun, 1)); > /* do more stuff with fun */ > UNPROTECT(2); > but I think it is useful to know that the vector accessors and mutators do > not allocate memory. > > > A stack imbalance is often due to different numbers of PROTECTs on > different code paths. These are slightly annoying and become more frequent > if you use more PROTECTs. On the other hand, R does detect them for you. > If you don't use enough PROTECTs you get bugs that are very hard to track > down [the best bet is probably valgrind + gctorture() to provoke them into > showing themselves early, but that's only available on Linux]. > > -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
