Re: [Rd] package dependencies
> "SF" == Seth Falcon <[EMAIL PROTECTED]>
> on Wed, 15 Aug 2007 16:59:01 -0700 writes:
SF> Zhenhuan Cui <[EMAIL PROTECTED]> writes:
>> I created an add-on R package. In this package, there is
>> a line "require(pckgname)", because I need to call some
>> functions in pckgname. My package is successfully built
>> and can be successful installed. But R CMD check can not
>> be executed. The error message is:
.
SF> Instead of require(pkgname), simply list pkgname in the
SF> Depends field of your package's DESCRIPTION file. See
SF> the Writing R Extensions manual for details.
But he still must make sure that "R CMD check" has 'pkgname'
in its R_LIBS :
>> Actually, before running R CMD check, I run the command "set
>> R_LIBS=/home/myname/MyRLibrary". It is the directory where pckgname is
>> installed.
>> What else should I do so that I can pass R CMD check?
Instead of 'set R_LIBS=' {which seems to indicate you use a csh-alike}
use
setenv R_LIBS=.
R CMD check
or --- typically better, since the R_LIBS setting remains "local" ---
env R_LIBS=... R CMD check https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Advice on parsing / overriding function calls
Hi,
I am trying to tighten file I/O security on a process that passes a
user-supplied script to R CMD Batch. Broadly speaking, I'd like to restrict
I/O to a designated path on the file system. Right now, I'm trying to
address this in the R environment by forcing the script to use modified
versions of scan, read.table, sys.load.image, etc.
I can run a replace string on the user-supplied script so that, for example,
"scan(" is replaced by "safe.scan("
e.g.
> SafePath <- function(file)
{fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp[[1]])],sep="/")}
> SafePath("/etc/passwd")
[1] "safepath/passwd"
> Safe.scan <- function(file, ...) scan(SafePath(file),...)
> Safe.scan("/etc/passwd",what="",sep="\n")
Error in file(file, "r") : unable to open connection
In addition: Warning message:
cannot open file 'safepath/passwd', reason 'No such file or directory'
I'd appreciate any critique of this approach. Is there something more
effective or elegant?
Regards,
Mike
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods and try() [R-devel]
On Wed, 15 Aug 2007, Byron Ellis wrote: > Hi all, I'm having a problem with some sort of interaction with try() > and methods, I think. > > The setup is as follows, I have an S4 class that holds an environment > and I would like to evaluate the right hand side of a function inside > that environment. No problem there. > > However, if the formula involves a symbol that doesn't exist, which > may or may not happen, it fails as it should and reports and error > "blah blah does not exist." As it should. > > When I wrap that same call in a try() statement, the error becomes "no > function to return from, jumping to top level," bypassing the try > statement and generally wreaking havoc. Any clues what might be > causing this? Yes. There is no context on the stack that corresponds to the environment to which a jump is to be made. Why that is the case is impossible to tell without a simple reproducible example. Best, luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
What are you trying to defend against? A serious attacker could still
use rm/assign/get/eval/... to circumvent your replaced functions. I
think it would be very difficult (if not impossible) to prevent this
from happening), especially if the user can load packages.
Hadley
On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying to tighten file I/O security on a process that passes a
> user-supplied script to R CMD Batch. Broadly speaking, I'd like to restrict
> I/O to a designated path on the file system. Right now, I'm trying to
> address this in the R environment by forcing the script to use modified
> versions of scan, read.table, sys.load.image, etc.
>
> I can run a replace string on the user-supplied script so that, for example,
> "scan(" is replaced by "safe.scan("
>
> e.g.
>
> > SafePath <- function(file)
> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp[[1]])],sep="/")}
> > SafePath("/etc/passwd")
> [1] "safepath/passwd"
>
> > Safe.scan <- function(file, ...) scan(SafePath(file),...)
> > Safe.scan("/etc/passwd",what="",sep="\n")
> Error in file(file, "r") : unable to open connection
> In addition: Warning message:
> cannot open file 'safepath/passwd', reason 'No such file or directory'
>
> I'd appreciate any critique of this approach. Is there something more
> effective or elegant?
>
> Regards,
> Mike
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
Thanks for your note Hadley,
I would like to defend against a broad range of malicious activity, but the
focus of this module is to restrict file I/O to a specific area on the file
system. I agree that's it's impossible to prevent, but I'm trying to
increase the difficulty level.
The user is inhibited from installing or loading packages, calling eval, or
any file I/O functions directly. Their script is checked to against a
relatively long list of banned commands. I'm intending to run this check after
swapping calls to I/O functions to my safer versions. I think it would be
easy for the script to remove or modify my replacement functions, but not so
easy to modify them to something harmful.
I really do appreciate the critique, but I'm especially looking for advice
to improve on this.
Regards,
Mike
On 8/16/07, hadley wickham <[EMAIL PROTECTED]> wrote:
>
> What are you trying to defend against? A serious attacker could still
> use rm/assign/get/eval/... to circumvent your replaced functions. I
> think it would be very difficult (if not impossible) to prevent this
> from happening), especially if the user can load packages.
>
> Hadley
>
> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am trying to tighten file I/O security on a process that passes a
> > user-supplied script to R CMD Batch. Broadly speaking, I'd like to
> restrict
> > I/O to a designated path on the file system. Right now, I'm trying to
> > address this in the R environment by forcing the script to use modified
> > versions of scan, read.table, sys.load.image, etc.
> >
> > I can run a replace string on the user-supplied script so that, for
> example,
> > "scan(" is replaced by "safe.scan("
> >
> > e.g.
> >
> > > SafePath <- function(file)
> >
> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp[[1]])],sep="/")}
> > > SafePath("/etc/passwd")
> > [1] "safepath/passwd"
> >
> > > Safe.scan <- function(file, ...) scan(SafePath(file),...)
> > > Safe.scan("/etc/passwd",what="",sep="\n")
> > Error in file(file, "r") : unable to open connection
> > In addition: Warning message:
> > cannot open file 'safepath/passwd', reason 'No such file or directory'
> >
> > I'd appreciate any critique of this approach. Is there something more
> > effective or elegant?
> >
> > Regards,
> > Mike
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> http://had.co.nz/
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] call R function in c++ program
Hi all
I don't know if my message are correct in this forums.
I create a program in c++ who use statistical function. I want to execute
this function in R (in particular for use packages ade4, lattice,
bioconductor...)
Until now, my program work for simple function ("plot", "rnorm"...) but I
can't use library
My class are :
// in constructor
int argc = 1;
char *argv[] = {"wxR"};
Rf_initEmbeddedR(argc, argv);
rho = R_GlobalEnv;
// in destructor
Rf_endEmbeddedR(0);
// for translate std::vector to SEXP VECTOR
// std_vector are defined as "vector" and iterator as
"vector::iterator"
PROTECT( vector_SEXP = allocVector(REALSXP, std_vector.size()) );
int i = 0;
for(std_iterator s_it=std_vector.begin(); s_it!=std_vector.end();
s_it++)
{
REAL(vector_SEXP)[i] = (double) *s_it;
i++;
}
UNPROTECT(1);
// for create a variable in R environement
defineVar(install("variable_name"), variable_value_SEXP, rho);
// for execute "complex" function (with parser)
PROTECT( e1 = mkString("plot(variable_name, type=\"l\")") );
PROTECT( e2 = R_ParseVector(e1, 1, &status, R_NilValue) );
R_tryEval(VECTOR_ELT(e2,0), rho, &hadError);
UNPROTECT(2);
// for execute "simple" function (without parser)
PROTECT( e1 = lang3(install(":"), ScalarInteger(1), ScalarInteger(4))
);
PROTECT( e2 = lang4(install("matrix"), e1, ScalarInteger(4),
ScalarInteger(1)) );
PROTECT( e3 = lang2(install("layout"), e2) );
eval(e3,R_GlobalEnv);
UNPROTECT(3);
// for call library (using parser)
PROTECT( e1 = mkString("library(ade4, logical.return=TRUE);
PROTECT( e2 = R_ParseVector(e1, 1, &status, R_NilValue) );
e3 = R_tryEval(VECTOR_ELT(e2,0), rho, &hadError);
UNPROTECT(2);
if(LOGICAL(e3)[0])
// succes
else
// echec
Until this point, all my function succes !
When I try to call function in ade4 library, I have error 1 :
PROTECT( e1 = mkString("a<-dudi.pca(b,scannf=FALSE, nf=2)")
PROTECT( e2 = R_ParseVector(e1, 1, &status, R_NilValue) );
R_tryEval(VECTOR_ELT(e2,0), rho, &hadError);
UNPROTECT(2);
You know where come from the problem ?
Bonus question 1 :
I can't call directely the function plot(x, type="l") without parser.
if I try somthing like this, it's doesn't work :
PROTECT( e2 = lang4(install("type"), mkChar("l")) );
PROTECT( e3 = lang3(install("plot"), e1, e2) );
eval(e3,R_GlobalEnv);
UNPROTECT(3);
How can I resolve this ?
Bonus question 2 :
When I call some "plot" function, my program crash. And I don't khow why
Thanks for yours suggests
--
View this message in context:
http://www.nabble.com/call-R-function-in-c%2B%2B-program-tf4279222.html#a12180033
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
Well, I think there are some serious use e.g. offering a web server
for script uploaded then downloading the Rout result back...
The issue is more about whether he wants to limit *all* file system
access or just limiting to certain areas. For the former,
I would set up a chroot jail and run R from within; for the latter,
I would probably do something with LD_LIBRARY_PRELOAD to override
all the file system accessing functions in libc directly, really.
That would fix the problem with system(rm) and some such, I think,
because if your entire R process and any sub-process R launches has no
access to the genuine libc fwrite/fread/etc functions you cannot do
any demage, right?
Both are tricky and take time to do (the chroot jail a bit easier,
actually...), but quite do-able.
It depends on (1) how paranoid you are, (2) how much trouble you want to
have for yourself to achieve those restrictions...
hadley wickham wrote:
> What are you trying to defend against? A serious attacker could still
> use rm/assign/get/eval/... to circumvent your replaced functions. I
> think it would be very difficult (if not impossible) to prevent this
> from happening), especially if the user can load packages.
>
> Hadley
>
> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am trying to tighten file I/O security on a process that passes a
>> user-supplied script to R CMD Batch. Broadly speaking, I'd like to restrict
>> I/O to a designated path on the file system. Right now, I'm trying to
>> address this in the R environment by forcing the script to use modified
>> versions of scan, read.table, sys.load.image, etc.
>>
>> I can run a replace string on the user-supplied script so that, for example,
>> "scan(" is replaced by "safe.scan("
>>
>> e.g.
>>
>>> SafePath <- function(file)
>> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp[[1]])],sep="/")}
>>> SafePath("/etc/passwd")
>> [1] "safepath/passwd"
>>
>>> Safe.scan <- function(file, ...) scan(SafePath(file),...)
>>> Safe.scan("/etc/passwd",what="",sep="\n")
>> Error in file(file, "r") : unable to open connection
>> In addition: Warning message:
>> cannot open file 'safepath/passwd', reason 'No such file or directory'
>>
>> I'd appreciate any critique of this approach. Is there something more
>> effective or elegant?
>>
>> Regards,
>> Mike
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
> The issue is more about whether he wants to limit *all* file system
> access or just limiting to certain areas. For the former,
> I would set up a chroot jail and run R from within; for the latter,
> I would probably do something with LD_LIBRARY_PRELOAD to override
> all the file system accessing functions in libc directly, really.
> That would fix the problem with system(rm) and some such, I think,
> because if your entire R process and any sub-process R launches has no
> access to the genuine libc fwrite/fread/etc functions you cannot do
> any demage, right?
> Both are tricky and take time to do (the chroot jail a bit easier,
> actually...), but quite do-able.
a sneaky trick:
for each compute session, automate setting up a zone ("solaris
containers") on a solaris 10+ box. if you have a
preinstalled/preconfigured zone template, snapshotted with zfs, you can
roll out a new compute zone in literally seconds. you can quota it, limit
the amount of CPU it gets, etc. really not very difficult at all to set
up. sun's tools are *great* for this nowadays.
this is substantially safer than chroot() or LD_PRELOAD tricks, and lets
you do this stuff without having to invent the wheel.
it also reduces overhead to the point where you really *can* set up a
naked compute (well, with R in it...) environment for every compute
session getting instantiated. in way, way, way less time than it takes
for the computations to actually run.
if someone does system(rm) in a container... who cares? they just trashed
their own session, and nothing else. just blow the trashed ones away
periodically.
--e
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
Thinking along these lines, we actually have a mechanism for
replacing the system call (it's used by the Mac GUI to allow root
calls) and one could think of expanding this to all critical
operations. Clearly, there are issues (speed for example), but it
would be nice to have a 'fortified' version of R that allows turing
on restrictions. I don't think it's easy, but given the rising demand
(at least in my perception), it would be interesting to see how far
we can get.
Re filtering strings in commands - I don't think this will work,
because you can compute on the language, so you can construct
arbitrary calls without using the names in verbatim, so it is
possible to circumvent such filters fairly easily.
Cheers,
Simon
On Aug 16, 2007, at 9:23 AM, Hin-Tak Leung wrote:
> Well, I think there are some serious use e.g. offering a web server
> for script uploaded then downloading the Rout result back...
>
> The issue is more about whether he wants to limit *all* file system
> access or just limiting to certain areas. For the former,
> I would set up a chroot jail and run R from within; for the latter,
> I would probably do something with LD_LIBRARY_PRELOAD to override
> all the file system accessing functions in libc directly, really.
> That would fix the problem with system(rm) and some such, I think,
> because if your entire R process and any sub-process R launches has no
> access to the genuine libc fwrite/fread/etc functions you cannot do
> any demage, right?
> Both are tricky and take time to do (the chroot jail a bit easier,
> actually...), but quite do-able.
>
> It depends on (1) how paranoid you are, (2) how much trouble you
> want to
> have for yourself to achieve those restrictions...
>
> hadley wickham wrote:
>> What are you trying to defend against? A serious attacker could
>> still
>> use rm/assign/get/eval/... to circumvent your replaced functions. I
>> think it would be very difficult (if not impossible) to prevent this
>> from happening), especially if the user can load packages.
>>
>> Hadley
>>
>> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> I am trying to tighten file I/O security on a process that passes a
>>> user-supplied script to R CMD Batch. Broadly speaking, I'd like
>>> to restrict
>>> I/O to a designated path on the file system. Right now, I'm
>>> trying to
>>> address this in the R environment by forcing the script to use
>>> modified
>>> versions of scan, read.table, sys.load.image, etc.
>>>
>>> I can run a replace string on the user-supplied script so that,
>>> for example,
>>> "scan(" is replaced by "safe.scan("
>>>
>>> e.g.
>>>
SafePath <- function(file)
>>> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp
>>> [[1]])],sep="/")}
SafePath("/etc/passwd")
>>> [1] "safepath/passwd"
>>>
Safe.scan <- function(file, ...) scan(SafePath(file),...)
Safe.scan("/etc/passwd",what="",sep="\n")
>>> Error in file(file, "r") : unable to open connection
>>> In addition: Warning message:
>>> cannot open file 'safepath/passwd', reason 'No such file or
>>> directory'
>>>
>>> I'd appreciate any critique of this approach. Is there something
>>> more
>>> effective or elegant?
>>>
>>> Regards,
>>> Mike
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
On Thu, 16 Aug 2007, Simon Urbanek wrote:
> Thinking along these lines, we actually have a mechanism for
> replacing the system call (it's used by the Mac GUI to allow root
> calls) and one could think of expanding this to all critical
> operations. Clearly, there are issues (speed for example), but it
> would be nice to have a 'fortified' version of R that allows turing
> on restrictions. I don't think it's easy, but given the rising demand
> (at least in my perception), it would be interesting to see how far
> we can get.
>
> Re filtering strings in commands - I don't think this will work,
> because you can compute on the language, so you can construct
> arbitrary calls without using the names in verbatim, so it is
> possible to circumvent such filters fairly easily.
Exactly. All I would need is access to a file() connection, and I could
easily do that in such a way that 'file' never appeared in the script.
And I've thought of half a dozen backdoors that have not been mentioned in
this thread.
I am not sure there is really much point in trying to fortify R, when
that's the OS's job and it may well be better to run R in a suitable
sandbox. Certainly I think that is the solution for web services.
One area where it may be necessary is embedded applications. Certainly if
R is embedded into the same process (which is how R as an shlib or DLL is
usually used) then you may want the main application to have privileges
you do not give to the embedded R. But using a separate process (e.g. via
Rserve) may be more secure.
>
> Cheers,
> Simon
>
> On Aug 16, 2007, at 9:23 AM, Hin-Tak Leung wrote:
>
>> Well, I think there are some serious use e.g. offering a web server
>> for script uploaded then downloading the Rout result back...
>>
>> The issue is more about whether he wants to limit *all* file system
>> access or just limiting to certain areas. For the former,
>> I would set up a chroot jail and run R from within; for the latter,
>> I would probably do something with LD_LIBRARY_PRELOAD to override
>> all the file system accessing functions in libc directly, really.
>> That would fix the problem with system(rm) and some such, I think,
>> because if your entire R process and any sub-process R launches has no
>> access to the genuine libc fwrite/fread/etc functions you cannot do
>> any demage, right?
>> Both are tricky and take time to do (the chroot jail a bit easier,
>> actually...), but quite do-able.
>>
>> It depends on (1) how paranoid you are, (2) how much trouble you
>> want to
>> have for yourself to achieve those restrictions...
>>
>> hadley wickham wrote:
>>> What are you trying to defend against? A serious attacker could
>>> still
>>> use rm/assign/get/eval/... to circumvent your replaced functions. I
>>> think it would be very difficult (if not impossible) to prevent this
>>> from happening), especially if the user can load packages.
>>>
>>> Hadley
>>>
>>> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
Hi,
I am trying to tighten file I/O security on a process that passes a
user-supplied script to R CMD Batch. Broadly speaking, I'd like
to restrict
I/O to a designated path on the file system. Right now, I'm
trying to
address this in the R environment by forcing the script to use
modified
versions of scan, read.table, sys.load.image, etc.
I can run a replace string on the user-supplied script so that,
for example,
"scan(" is replaced by "safe.scan("
e.g.
> SafePath <- function(file)
{fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp
[[1]])],sep="/")}
> SafePath("/etc/passwd")
[1] "safepath/passwd"
> Safe.scan <- function(file, ...) scan(SafePath(file),...)
> Safe.scan("/etc/passwd",what="",sep="\n")
Error in file(file, "r") : unable to open connection
In addition: Warning message:
cannot open file 'safepath/passwd', reason 'No such file or
directory'
I'd appreciate any critique of this approach. Is there something
more
effective or elegant?
Regards,
Mike
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods and try() [R-devel]
On 8/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote: > On Wed, 15 Aug 2007, Byron Ellis wrote: > > > Hi all, I'm having a problem with some sort of interaction with try() > > and methods, I think. > > > > The setup is as follows, I have an S4 class that holds an environment > > and I would like to evaluate the right hand side of a function inside > > that environment. No problem there. > > > > However, if the formula involves a symbol that doesn't exist, which > > may or may not happen, it fails as it should and reports and error > > "blah blah does not exist." As it should. > > > > When I wrap that same call in a try() statement, the error becomes "no > > function to return from, jumping to top level," bypassing the try > > statement and generally wreaking havoc. Any clues what might be > > causing this? > > Yes. There is no context on the stack that corresponds to the > environment to which a jump is to be made. Why that is the case is > impossible to tell without a simple reproducible example. I have a sinking feeling that generating a good reduction will also find my bug. :-) I was mostly wondering if there had been a recent change in the try() machinery. In any case, I'll keep hunting for the problem. > > Best, > > luke > > > -- > Luke Tierney > Chair, Statistics and Actuarial Science > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: [EMAIL PROTECTED] > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
Thanks everyone for these comments, they're great. I see the exposure
points and your collective comments have given me a lot to think about.
Eventually, I will need a "sandbox" solution. I think I'll be needing help,
and if there are any freelancers interested in discussing offline, please
contact me. Hopefully that doesn't violate posting guidelines ;)
Thanks again, all.
Best regards, Mike
On 8/16/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> On Thu, 16 Aug 2007, Simon Urbanek wrote:
>
> > Thinking along these lines, we actually have a mechanism for
> > replacing the system call (it's used by the Mac GUI to allow root
> > calls) and one could think of expanding this to all critical
> > operations. Clearly, there are issues (speed for example), but it
> > would be nice to have a 'fortified' version of R that allows turing
> > on restrictions. I don't think it's easy, but given the rising demand
> > (at least in my perception), it would be interesting to see how far
> > we can get.
> >
> > Re filtering strings in commands - I don't think this will work,
> > because you can compute on the language, so you can construct
> > arbitrary calls without using the names in verbatim, so it is
> > possible to circumvent such filters fairly easily.
>
> Exactly. All I would need is access to a file() connection, and I could
> easily do that in such a way that 'file' never appeared in the script.
> And I've thought of half a dozen backdoors that have not been mentioned in
> this thread.
>
> I am not sure there is really much point in trying to fortify R, when
> that's the OS's job and it may well be better to run R in a suitable
> sandbox. Certainly I think that is the solution for web services.
>
> One area where it may be necessary is embedded applications. Certainly if
> R is embedded into the same process (which is how R as an shlib or DLL is
> usually used) then you may want the main application to have privileges
> you do not give to the embedded R. But using a separate process (e.g. via
> Rserve) may be more secure.
>
> >
> > Cheers,
> > Simon
> >
> > On Aug 16, 2007, at 9:23 AM, Hin-Tak Leung wrote:
> >
> >> Well, I think there are some serious use e.g. offering a web server
> >> for script uploaded then downloading the Rout result back...
> >>
> >> The issue is more about whether he wants to limit *all* file system
> >> access or just limiting to certain areas. For the former,
> >> I would set up a chroot jail and run R from within; for the latter,
> >> I would probably do something with LD_LIBRARY_PRELOAD to override
> >> all the file system accessing functions in libc directly, really.
> >> That would fix the problem with system(rm) and some such, I think,
> >> because if your entire R process and any sub-process R launches has no
> >> access to the genuine libc fwrite/fread/etc functions you cannot do
> >> any demage, right?
> >> Both are tricky and take time to do (the chroot jail a bit easier,
> >> actually...), but quite do-able.
> >>
> >> It depends on (1) how paranoid you are, (2) how much trouble you
> >> want to
> >> have for yourself to achieve those restrictions...
> >>
> >> hadley wickham wrote:
> >>> What are you trying to defend against? A serious attacker could
> >>> still
> >>> use rm/assign/get/eval/... to circumvent your replaced functions. I
> >>> think it would be very difficult (if not impossible) to prevent this
> >>> from happening), especially if the user can load packages.
> >>>
> >>> Hadley
> >>>
> >>> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying to tighten file I/O security on a process that passes a
> user-supplied script to R CMD Batch. Broadly speaking, I'd like
> to restrict
> I/O to a designated path on the file system. Right now, I'm
> trying to
> address this in the R environment by forcing the script to use
> modified
> versions of scan, read.table, sys.load.image, etc.
>
> I can run a replace string on the user-supplied script so that,
> for example,
> "scan(" is replaced by "safe.scan("
>
> e.g.
>
> > SafePath <- function(file)
> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp
> [[1]])],sep="/")}
> > SafePath("/etc/passwd")
> [1] "safepath/passwd"
>
> > Safe.scan <- function(file, ...) scan(SafePath(file),...)
> > Safe.scan("/etc/passwd",what="",sep="\n")
> Error in file(file, "r") : unable to open connection
> In addition: Warning message:
> cannot open file 'safepath/passwd', reason 'No such file or
> directory'
>
> I'd appreciate any critique of this approach. Is there something
> more
> effective or elegant?
>
> Regards,
> Mike
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Pa
Re: [Rd] methods and try() [R-devel]
On Thu, 16 Aug 2007, Byron Ellis wrote: > On 8/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote: >> On Wed, 15 Aug 2007, Byron Ellis wrote: >> >>> Hi all, I'm having a problem with some sort of interaction with try() >>> and methods, I think. >>> >>> The setup is as follows, I have an S4 class that holds an environment >>> and I would like to evaluate the right hand side of a function inside >>> that environment. No problem there. >>> >>> However, if the formula involves a symbol that doesn't exist, which >>> may or may not happen, it fails as it should and reports and error >>> "blah blah does not exist." As it should. >>> >>> When I wrap that same call in a try() statement, the error becomes "no >>> function to return from, jumping to top level," bypassing the try >>> statement and generally wreaking havoc. Any clues what might be >>> causing this? >> >> Yes. There is no context on the stack that corresponds to the >> environment to which a jump is to be made. Why that is the case is >> impossible to tell without a simple reproducible example. > > I have a sinking feeling that generating a good reduction will also > find my bug. :-) I was mostly wondering if there had been a recent > change in the try() machinery. In any case, I'll keep hunting for the > problem. There sae, at 2.5.0 I believe. At that point try was reimplemented in terms of tryCatch. That may have uncovered a bug in our code or yours, but without a reproducible example it's hard to say more. Best, luke > >> >> Best, >> >> luke >> >> >> -- >> Luke Tierney >> Chair, Statistics and Actuarial Science >> Ralph E. Wareham Professor of Mathematical Sciences >> University of Iowa Phone: 319-335-3386 >> Department of Statistics andFax: 319-335-3017 >> Actuarial Science >> 241 Schaeffer Hall email: [EMAIL PROTECTED] >> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu >> > > > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods and try() [R-devel]
On 8/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
>
> There sae, at 2.5.0 I believe. At that point try was reimplemented in
> terms of tryCatch. That may have uncovered a bug in our code or
> yours, but without a reproducible example it's hard to say more.
An indeed, I believe I've got one. Turns out it didn't solve my
problem though. So, imagine we have a method (with a new generic).
Say,
setGeneric("glue",function(a,b) standardGeneric("glue"))
setMethod("glue",signature("character","character"),function(a,b) {
paste(a,b,sep="")
})
Trying the code:
> glue("A","B")
[1] "AB"
> glue("A",B)
Error: object "B" not found
Error in glue("A", B) :
error in evaluating the argument 'b' in selecting a method for function 'glue'
Good. Works as expected (there's no B in the environment). However,
I'd expect try to work...
> try(glue("A",B))
Error: no function to return from, jumping to top level
Error in glue("A", B) :
error in evaluating the argument 'b' in selecting a method for function 'glue'
with silent=TRUE the "jumping to top level" is not caught and causes
scripts to bail out.
Hopefully that helps?
>
> Best,
>
> luke
>
>
> >
> >>
> >> Best,
> >>
> >> luke
> >>
> >>
> >> --
> >> Luke Tierney
> >> Chair, Statistics and Actuarial Science
> >> Ralph E. Wareham Professor of Mathematical Sciences
> >> University of Iowa Phone: 319-335-3386
> >> Department of Statistics andFax: 319-335-3017
> >> Actuarial Science
> >> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> >> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
> >>
> >
> >
> >
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
--
Byron Ellis ([EMAIL PROTECTED])
"Oook" -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods and try() [R-devel]
I think I understand the issue. The methods code uses R_tryCatch
internally in a few places, hoping I think for a C level variant of
tryCatch. It isn't meant to be used that way. It is intended only
for use in embedded contexts where there is no proper top level, or
possibly in contexts where conceptually the evaluation is happening in
a seperate thread of execution. In particular R_tryEval establishes
it's own top level (and that is the top level that is being jumped
to):
> { try(glue("A",B)); 2}
Error: no function to return from, jumping to top level
Error in glue("A", B) :
error in evaluating the argument 'b' in selecting a method for function
'glue'
[1] 2
>
Because of the "internal" top level established by R_tryEval there is
no way to jump from inside the eval to an outer context, which is what
needs to happen for try() to work here.
It looks like the intent in methods_list_dispatch.c in all but one
case is to catch the error and report something a bit more meaningful;
in the one other case, in R_nextMethodCall, there is also a cleanup
action that occurs before resignaling the error.
To fix this will I think require designing a C level tryCatch. That
will take a bit of time to get right. Not sure if it will get done by
2.6.0. There may be a quick temporary fix but I'm not seeing one at
this point.
Arguably R_tryEval in its present form should also ensure that the
handler stacks are empty in the call (not an issue for the intended
embedded usage). Need to think about that a bit as well.
Best,
luke
On Thu, 16 Aug 2007, Byron Ellis wrote:
> On 8/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
>>
>> There sae, at 2.5.0 I believe. At that point try was reimplemented in
>> terms of tryCatch. That may have uncovered a bug in our code or
>> yours, but without a reproducible example it's hard to say more.
>
> An indeed, I believe I've got one. Turns out it didn't solve my
> problem though. So, imagine we have a method (with a new generic).
> Say,
>
> setGeneric("glue",function(a,b) standardGeneric("glue"))
> setMethod("glue",signature("character","character"),function(a,b) {
> paste(a,b,sep="")
> })
>
> Trying the code:
>
>> glue("A","B")
> [1] "AB"
>> glue("A",B)
> Error: object "B" not found
> Error in glue("A", B) :
> error in evaluating the argument 'b' in selecting a method for function
> 'glue'
>
> Good. Works as expected (there's no B in the environment). However,
> I'd expect try to work...
>
>> try(glue("A",B))
> Error: no function to return from, jumping to top level
> Error in glue("A", B) :
> error in evaluating the argument 'b' in selecting a method for function
> 'glue'
>
> with silent=TRUE the "jumping to top level" is not caught and causes
> scripts to bail out.
>
> Hopefully that helps?
>
>
>>
>> Best,
>>
>> luke
>>
>>
>>>
Best,
luke
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>>>
>>>
>>>
>>
>> --
>> Luke Tierney
>> Chair, Statistics and Actuarial Science
>> Ralph E. Wareham Professor of Mathematical Sciences
>> University of Iowa Phone: 319-335-3386
>> Department of Statistics andFax: 319-335-3017
>> Actuarial Science
>> 241 Schaeffer Hall email: [EMAIL PROTECTED]
>> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>>
>
>
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods and try() [R-devel]
On 8/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
> I think I understand the issue. The methods code uses R_tryCatch
> internally in a few places, hoping I think for a C level variant of
> tryCatch. It isn't meant to be used that way. It is intended only
> for use in embedded contexts where there is no proper top level, or
> possibly in contexts where conceptually the evaluation is happening in
> a seperate thread of execution. In particular R_tryEval establishes
> it's own top level (and that is the top level that is being jumped
> to):
>
> > { try(glue("A",B)); 2}
> Error: no function to return from, jumping to top level
> Error in glue("A", B) :
>error in evaluating the argument 'b' in selecting a method for function
> 'glue'
> [1] 2
> >
>
> Because of the "internal" top level established by R_tryEval there is
> no way to jump from inside the eval to an outer context, which is what
> needs to happen for try() to work here.
>
> It looks like the intent in methods_list_dispatch.c in all but one
> case is to catch the error and report something a bit more meaningful;
> in the one other case, in R_nextMethodCall, there is also a cleanup
> action that occurs before resignaling the error.
Yes, there seems to be some new (and much appreciated) error reporting
that goes on in recent versions of R-devel that gives a stack trace of
method calls instead of telling us that ".local" has failed, which was
less useful.
>
> To fix this will I think require designing a C level tryCatch. That
> will take a bit of time to get right. Not sure if it will get done by
> 2.6.0. There may be a quick temporary fix but I'm not seeing one at
> this point.
>
> Arguably R_tryEval in its present form should also ensure that the
> handler stacks are empty in the call (not an issue for the intended
> embedded usage). Need to think about that a bit as well.
Ah, that's unfortunate. I guess I will have to back out that feature
for the time being.
>
> Best,
>
> luke
>
> On Thu, 16 Aug 2007, Byron Ellis wrote:
>
> > On 8/16/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
> >>
> >> There sae, at 2.5.0 I believe. At that point try was reimplemented in
> >> terms of tryCatch. That may have uncovered a bug in our code or
> >> yours, but without a reproducible example it's hard to say more.
> >
> > An indeed, I believe I've got one. Turns out it didn't solve my
> > problem though. So, imagine we have a method (with a new generic).
> > Say,
> >
> > setGeneric("glue",function(a,b) standardGeneric("glue"))
> > setMethod("glue",signature("character","character"),function(a,b) {
> > paste(a,b,sep="")
> > })
> >
> > Trying the code:
> >
> >> glue("A","B")
> > [1] "AB"
> >> glue("A",B)
> > Error: object "B" not found
> > Error in glue("A", B) :
> > error in evaluating the argument 'b' in selecting a method for function
> > 'glue'
> >
> > Good. Works as expected (there's no B in the environment). However,
> > I'd expect try to work...
> >
> >> try(glue("A",B))
> > Error: no function to return from, jumping to top level
> > Error in glue("A", B) :
> > error in evaluating the argument 'b' in selecting a method for function
> > 'glue'
> >
> > with silent=TRUE the "jumping to top level" is not caught and causes
> > scripts to bail out.
> >
> > Hopefully that helps?
> >
> >
> >>
> >> Best,
> >>
> >> luke
> >>
> >>
> >>>
>
> Best,
>
> luke
>
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Luke Tierney
> >> Chair, Statistics and Actuarial Science
> >> Ralph E. Wareham Professor of Mathematical Sciences
> >> University of Iowa Phone: 319-335-3386
> >> Department of Statistics andFax: 319-335-3017
> >> Actuarial Science
> >> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> >> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
> >>
> >
> >
> >
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
--
Byron Ellis ([EMAIL PROTECTED])
"Oook" -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
