[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
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
>
>
--
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] Suggest patch for princomp.formula and prcomp.formula
G'day Brian,
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:
BDR> The proposed fix regretably will not work, since one can do
BDR> things like
BDR> library(MASS)
BDR> prcomp(~ dist + dist:climb, hills)
Yes, I had the impression that this would work with the current
version but dismissed it as unintentional. ;-)
I wouldn't expect anyone to specify interaction terms in a principal
components analysis, but perhaps there are valid reasons to do so.
Attached is a slightly modified patch which still allows the above
example but also the changes that I proposed. On my machine, R-devel
with this patch passes "make check FORCE=FORCE" and produces the
following output:
> library(DAAG)
> res <- prcomp(~ . - case - site - Pop - sex, possum)
> res <- princomp(~ . - case - site - Pop - sex, possum)
> res <- prcomp(~ . - case - site - Pop, possum)
Error in prcomp.formula(~. - case - site - Pop, possum) :
PCA applies only to numerical variables
> res <- princomp(~ . - case - site - Pop, possum)
Error in princomp.formula(~. - case - site - Pop, possum) :
PCA applies only to numerical variables
> library(MASS)
Attaching package: 'MASS'
The following object(s) are masked from package:DAAG :
hills
> prcomp(~ dist + dist:climb, hills)
Standard deviations:
[1] 29655.128279 3.101566
Rotation:
PC1 PC2
dist -0.000154139 -0.99988
dist:climb -0.99988 0.000154139
Cheers,
Berwin
Index: src/library/stats/R/princomp.R
===
--- src/library/stats/R/princomp.R (revision 37574)
+++ src/library/stats/R/princomp.R (working copy)
@@ -10,13 +10,15 @@
mf$... <- NULL
mf[[1]] <- as.name("model.frame")
mf <- eval.parent(mf)
+na.act <- attr(mf, "na.action")
+mt <- attr(mf, "terms") # allow model.frame to update it
+attr(mt, "intercept") <- 0
+mterms <- attr(mt, "factors")
+mterms <- rownames(mterms)[apply(mterms, 1, any)]
## this is not a `standard' model-fitting function,
## so no need to consider contrasts or levels
-if(any(sapply(mf, function(x) is.factor(x) || !is.numeric(x
+if(any(sapply(mterms, function(x) is.factor(mf[,x]) ||
!is.numeric(mf[,x]
stop("PCA applies only to numerical variables")
-na.act <- attr(mf, "na.action")
-mt <- attr(mf, "terms") # allow model.frame to update it
-attr(mt, "intercept") <- 0
x <- model.matrix(mt, mf)
res <- princomp.default(x, ...)
## fix up call to refer to the generic, but leave arg name as `formula'
Index: src/library/stats/R/prcomp.R
===
--- src/library/stats/R/prcomp.R(revision 37574)
+++ src/library/stats/R/prcomp.R(working copy)
@@ -37,13 +37,15 @@
mf$... <- NULL
mf[[1]] <- as.name("model.frame")
mf <- eval.parent(mf)
+na.act <- attr(mf, "na.action")
+mt <- attr(mf, "terms")
+attr(mt, "intercept") <- 0
+mterms <- attr(mt, "factors")
+mterms <- rownames(mterms)[apply(mterms, 1, any)]
## this is not a `standard' model-fitting function,
## so no need to consider contrasts or levels
-if (any(sapply(mf, function(x) is.factor(x) || !is.numeric(x
+if (any(sapply(mterms, function(x) is.factor(mf[,x]) ||
!is.numeric(mf[,x]
stop("PCA applies only to numerical variables")
-na.act <- attr(mf, "na.action")
-mt <- attr(mf, "terms")
-attr(mt, "intercept") <- 0
x <- model.matrix(mt, mf)
res <- prcomp.default(x, ...)
## fix up call to refer to the generic, but leave arg name as `formula'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ?symbols man page (PR#8713)
Full_Name: TOBY MARTHEWS Version: 2.2.1 OS: Windows XP Submission from: (NULL) (139.133.7.37) Just a small one, but it did trip me up today. On the ?symbols man page the following paragraph: inches: If 'inches' is 'FALSE', the units are taken to be those of the x axis... should say: inches: If 'inches' is 'FALSE', the units are taken to be those of the y axis... Thanks, Toby __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Safe to UNPROTECT() when object is assigned to a list?
Hi,
I'm troubleshooting some native code on Windows that very occationally
(and semi-randomly) crashes R. Already looked at "everything", I just
want to double check that it is safe to UNPROTECT() allocated
variables as soon as they are assigned to, say, a PROTECTed list.
>From (R v2.3.0) Section 5.7.1 "Handling the effects of garbage
collection" in "Writing R Extensions":
"In some cases it is necessary to keep better track of whether
protection is really needed. Be particularly aware of situations where
a large number of objects are generated. The pointer protection stack
has a fixed size (default 10,000) and can become full. It is not a
good idea then to just PROTECT everything in sight and UNPROTECT
several thousand objects at the end. It will almost invariably
possible to either assign the objects as part of another object (which
automatically protects them) or unprotect them immediately after use."
BTW, should it say "...another [protected] object..."?
Example from "5.7.4 Attributes" illustrating my question:
SEXP out(SEXP x, SEXP y)
{
R_len_t i, j, nx, ny;
double tmp;
SEXP ans, dim, dimnames;
nx = length(x); ny = length(y);
PROTECT(ans = allocVector(REALSXP, nx*ny));
for(i = 0; i < nx; i++) {
tmp = REAL(x)[i];
for(j = 0; j < ny; j++)
REAL(ans)[i + nx*j] = tmp * REAL(y)[j];
}
PROTECT(dim = allocVector(INTSXP, 2));
INTEGER(dim)[0] = nx; INTEGER(dim)[1] = ny;
setAttrib(ans, R_DimSymbol, dim);
*** It is safe to do UNPROTECT(1) for 'dim' already here, correct? ***
PROTECT(dimnames = allocVector(VECSXP, 2));
SET_VECTOR_ELT(dimnames, 0, getAttrib(x, R_NamesSymbol));
SET_VECTOR_ELT(dimnames, 1, getAttrib(y, R_NamesSymbol));
setAttrib(ans, R_DimNamesSymbol, dimnames);
UNPROTECT(3);
return(ans);
}
Thanks
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help please: please test timestamping of command history
On 3/27/2006 1:47 AM, Martin Maechler wrote:
> [from a semi-private diversion of the R-devel thread ]
>
>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>> on Sat, 25 Mar 2006 12:28:30 -0500 writes:
>
> Duncan> On 3/25/2006 11:30 AM, Martin Maechler wrote:
> >> Hi Duncan,
> >>
> >> I think all ESS users don't use history() because ESS
> >> calls R with "--no-readline" (Unix) or "--ess" (Windows &
> >> Cygwin)
> >>
> >> I'd wish that in that case, and probably also in BATCH
> >> mode, timestamp() should write the time stamp prefixed by
> >> "##" to the "R console" (to R's stdout); when people are
> >> using ESS properly, then rather than wanting a history,
> >> they save the R's buffer ("*R*") as "R transcript" (file
> >> typically ending with ".Rt" or ".Rout") and it makes much
> >> sense to have a time stampe entry in that file when
> >> others would want an entry in the history.
>
> Duncan> Thanks, that's a good suggestion. Do you know what
> Duncan> the test is for this state, in either R or C code?
> Duncan> capabilities() doesn't do it. Does ESS make itself
> Duncan> known to R code somehow?
>
> Yes, when ESS starts R (or S+) , it also issues
>
> options(STERM='iESS')
>
> and we (ESS core) thought that other GUIs / IDEs ideally should
> also set "STERM" - which AFAIK hasn't been adopted widely.
>
> hence if ( identical("iESS", getOption("STERM")) ) {
> ## are running 'inside ESS'
> }
>
> should be pretty reliable.
Thanks. The version that I committed yesterday defaulted to writing the
timestamp to the console as well as the history. Could you take a look,
and let me know if some special ESS behaviour is still needed?
Duncan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.3.0 scheduled for April 24, Grand-Feature freeze is active
The release of version 2.3.0 has been scheduled for April 24, 2006. The first alpha release should be available later today, once I have reviewed the build scripts. The detailed release schedule is as follows March 27: Declare start of release process. The build process is assumed to be essentially in place at this time. There is a "grand feature" freeze (minor tweaks can be applied, but no wholesale restructuring or API changes). Notice that wrapping a package in a namespace is a grand feature, and so is meddling with the event loop. Package maintainers should start adapting to any changes in base. Start making R-2.3.0-alpha.tar.gz packages automatically available. April 10: Feature freeze, simultaneously on base and recommended packages. It is assumed that all recommended packages pass their checks at this point. The API should not be touched. Start making R-2.3.0-beta.tar.gz packages automatically available. NEW: The R-2-3-patches SVN branch is created at this point. April 17: Code freeze. Only critical and/or trivial bugs fixed from this time onwards. Configure/make should only be touched in emergencies. NEW: Start making R-2.3.0-rc.tar.gz packages automatically available. April 24: Release. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Safe to UNPROTECT() when object is assigned to a list?
"Henrik Bengtsson" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm troubleshooting some native code on Windows that very occationally
> (and semi-randomly) crashes R. Already looked at "everything", I just
> want to double check that it is safe to UNPROTECT() allocated
> variables as soon as they are assigned to, say, a PROTECTed list.
>
> >From (R v2.3.0) Section 5.7.1 "Handling the effects of garbage
> collection" in "Writing R Extensions":
>
> "In some cases it is necessary to keep better track of whether
> protection is really needed. Be particularly aware of situations where
> a large number of objects are generated. The pointer protection stack
> has a fixed size (default 10,000) and can become full. It is not a
> good idea then to just PROTECT everything in sight and UNPROTECT
> several thousand objects at the end. It will almost invariably
> possible to either assign the objects as part of another object (which
> automatically protects them) or unprotect them immediately after use."
>
> BTW, should it say "...another [protected] object..."?
Yes. (And the text could need general rephrasing too. I'm afraid that
I'm the guilty party.)
> Example from "5.7.4 Attributes" illustrating my question:
>
> SEXP out(SEXP x, SEXP y)
> {
>R_len_t i, j, nx, ny;
>double tmp;
>SEXP ans, dim, dimnames;
>
>nx = length(x); ny = length(y);
>PROTECT(ans = allocVector(REALSXP, nx*ny));
>for(i = 0; i < nx; i++) {
> tmp = REAL(x)[i];
> for(j = 0; j < ny; j++)
>REAL(ans)[i + nx*j] = tmp * REAL(y)[j];
>}
>
>PROTECT(dim = allocVector(INTSXP, 2));
>INTEGER(dim)[0] = nx; INTEGER(dim)[1] = ny;
>setAttrib(ans, R_DimSymbol, dim);
>
>*** It is safe to do UNPROTECT(1) for 'dim' already here, correct? ***
Yes. The protection of "ans" will carry over to its attributes.
>PROTECT(dimnames = allocVector(VECSXP, 2));
>SET_VECTOR_ELT(dimnames, 0, getAttrib(x, R_NamesSymbol));
>SET_VECTOR_ELT(dimnames, 1, getAttrib(y, R_NamesSymbol));
>setAttrib(ans, R_DimNamesSymbol, dimnames);
>
>UNPROTECT(3);
>return(ans);
> }
>
> Thanks
>
> /Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Creating a package bundle.
Steve Su wrote:
> Dear All,
>
>
>
> What is the easiest way to create a package bundle in R? I have three
> packages I would like to group together in which one package will
> depends on three others. It looks like from
>
> http://tolstoy.newcastle.edu.au/R/help/01a/0284.html, all that is
> required is to put require in the .First? I wonder how one can create a
> package so that when it is downloaded,
>
> all the other packages are downloaded and installed as well? In my case,
> the three sub packages are not written by me and are already in R so I
> would like to keep the current
Perhaps you simply want to use
install.packages("the_package", dependencies = TRUE)
rather than building a package bundle of packages you are not
maintaining yourself.
Uwe Ligges
> versions as part of the bundle rather than allow them to get updated so
> there will not be compatibility problems?
>
>
>
> I am aware there is a writing R extensions guide but it seems to be
> geared towards a more advanced user rather than beginner like me?
>
>
>
> Thanks in advance.
>
>
>
> Steve.
>
>
> [[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] R 2.3.0 scheduled for April 24, Grand-Feature freeze is active
Peter Dalgaard <[EMAIL PROTECTED]> writes: > The release of version 2.3.0 has been scheduled for April 24, 2006. > > The first alpha release should be available later today, once I have > reviewed the build scripts. Done. The first version is now sitting in http://biostat.ku.dk/~pd/R-pre Further preliminary source releases will be made by a cron job at 4:05 (CET) each morning until release, provided the build process completes without error. Notice that the releases are only MINIMALLY CHECKED, we rely on your verification to get the remaining bugs out before the final release. They will be mirrored fairly quickly at the CRAN master site in Vienna, but might not percolate to the rest of CRAN before a new version has been made. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Creating a package bundle.
Hi Steve,
Are you sure you want a bundle? If you are writing your own package
Foo that depends on two pacakges already available via CRAN, then all
you need to do is list those two pacakges in the Depends field of your
package's DESCRIPTION file.
This will give you the automatic downloading of Foo's dependencies
when a user does: install.packages("foo", dependencies=TRUE)
As for the versions, you can specify required versions also in the
Depends field (see the writing R extensions guide).
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] not a problem: a submission (PR#8714)
Full_Name: TOBY MARTHEWS
Version: 2.1.1
OS: Windows XP
Submission from: (NULL) (139.133.7.38)
I think you should have better examples on the ?plot man page, if you don't mind
me saying. Can I suggest something like this, which would probably stop so many
emails to the R help about how to put on error bars
Cheers,
Toby M
**
xvalsT1=1:3
yvalsT1=c(10,20,30)
errplusT1=c(2,3,4)
errminusT1=c(9,8,7)
xvalsT2=1:3
yvalsT2=c(30,35,40)
errplusT2=c(12,13,14)
errminusT2=c(1,2,3)
treatment=c(rep("T1",times=length(xvalsT1)),rep("T2",times=length(xvalsT2)))
xvals=c(xvalsT1,xvalsT2)
yvals=c(yvalsT1,yvalsT2)
errplus=c(errplusT1,errplusT2)
errminus=c(errminusT1,errminusT2)
RGR=data.frame(treatment,xvals,yvals,errplus,errminus)
minx=min(RGR$xvals);maxx=max(RGR$xvals)
miny=min(RGR$yvals-RGR$errminus);maxy=max(RGR$yvals+RGR$errplus)
plot(x=0,y=0,type="n",xlim=c(minx,maxx),ylim=c(miny,maxy),lab=c(2,4,0),xlab="month",ylab="Relative
Growth Rate",axes=FALSE)
axis(1,at=1:3,month.abb[1:3])#axis(1,at=1:3,labels=c("Jan","Feb","Mar"))
has the
same effect
axis(2)
trts=c("T1","T2");syms=c(21,24)
for (i in 1:2) {
A=subset(RGR,treatment==trts[i])
points(x=A$xvals,y=A$yvals,pch=syms[i])
segments(A$xvals,A$yvals-A$errminus,A$xvals,A$yvals+A$errplus)#similar
to
symbols(x=A$xvals,y=A$yvals,boxplots=cbind(0,0,A$errminus,A$errplus,0.5),inches=FALSE,add=TRUE)
errwidth=0.015
segments(A$xvals-errwidth,A$yvals+A$errplus,A$xvals+errwidth,A$yvals+A$errplus)
segments(A$xvals-errwidth,A$yvals-A$errminus,A$xvals+errwidth,A$yvals-A$errminus)
lines(x=A$xvals,y=A$yvals,lty=syms[i])
}
#PS - this is a bit of an inelegant way to put on error bars, but to do better
you
#have to use commands like plotCI {gplots} or xYplot {Hmisc} - to learn more
look at
RSiteSearch("error bars")
legend(x=2.7,y=9,trts,pch=syms)#in same units as the axes
__
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] Operator masks in R, restrict set of applicable functions
On Mon, 27 Mar 2006, Michael Dondrup wrote:
> 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?
Yes. For base::system is just
> system
function (command, intern = FALSE, ignore.stderr = FALSE)
.Internal(system(if (ignore.stderr) paste(command, "2>/dev/null") else
command,
intern))
so you can just call the .Internal.
If designing R from scratch it would be a good idea to separate out all
the 'unsafe' (for a suitable definition) function and provide ways to lock
their internal code. Some of this would be fairly easy to do (e.g.
disabling the internals of system), but I am not sure a partial solution
would be much help. And disabling dyn.load would be almost impossible in
general use, as that would stop standard packages being loaded, and they
are loaded after user code (e.g. .Rprofile) is run.
> 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).
That is not clear to me. I thought you mentioned CGI, not a server
extension, so my understanding was that R was running in a separate
process from the server.
> 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
>>>
>>>
>>
>>
>
>
>
--
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
[Rd] Matrix inner product crashes on x86_64 (PR#8715)
Matrix inner product seems to crash R2.2.1 on a 64bit arch. More precisely, the crash happens atleast if the matrix is non-square. The bug can be reproduced (atleast here) with bash$ bin/R > X<-matrix(data=0,nrow=100,ncol=10); > mat<-X%*%t(X); Illegal instruction bash$ The crash doesnt happen if the matrix is specified square, e.g. 10x10. The underlying OS was Linux version 2.6.12-xeon-csl3 ([EMAIL PROTECTED]) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 SMP Wed Feb 22 18:34:17 EET 2006 and its running on Intel(R) Xeon(TM) MP CPU 3.66GHz. I configured R from the source tar.gz myself; each phase of "./configure --with-x=no ; make ; make install" passed without aborting on any errors. Cheers, J. --please do not edit the information below-- Version: platform = x86_64-unknown-linux-gnu arch = x86_64 os = linux-gnu system = x86_64, linux-gnu status = major = 2 minor = 2.1 year = 2005 month = 12 day = 20 svn rev = 36812 language = R Locale: [EMAIL PROTECTED];LC_NUMERIC=C;LC_TIME=en_US.ISO-8859-15;LC_COLLATE=en_US.ISO-8859-15;[EMAIL PROTECTED];LC_MESSAGES=en_US.ISO-8859-15;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix inner product crashes on x86_64 (PR#8715)
Not reproducible for me (and do you really think that something as simple as this would not have been found on x86_64 long before now?) This is almost certainly caused by your use of an inappropriate external BLAS. Something has probably been compiled for a different processor than the one you are using, since illegal instructions are a compiler (not R) issue that I have seen quite often on ix86 systems when this happened. Use --without-blas when recompiling R and see if it then works. On Mon, 27 Mar 2006, [EMAIL PROTECTED] wrote: > > Matrix inner product seems to crash R2.2.1 on a 64bit arch. > More precisely, the crash happens atleast if the matrix is > non-square. The bug can be reproduced (atleast here) with > > bash$ bin/R >> X<-matrix(data=0,nrow=100,ncol=10); >> mat<-X%*%t(X); > Illegal instruction > bash$ > > The crash doesnt happen if the matrix is specified square, > e.g. 10x10. The underlying OS was > > Linux version 2.6.12-xeon-csl3 ([EMAIL PROTECTED]) (gcc version 3.4.5 > 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 SMP Wed Feb 22 18:34:17 EET > 2006 > > and its running on Intel(R) Xeon(TM) MP CPU 3.66GHz. > > I configured R from the source tar.gz myself; each phase of > "./configure --with-x=no ; make ; make install" > passed without aborting on any errors. > > > Cheers, > J. > > --please do not edit the information below-- > > Version: > platform = x86_64-unknown-linux-gnu > arch = x86_64 > os = linux-gnu > system = x86_64, linux-gnu > status = > major = 2 > minor = 2.1 > year = 2005 > month = 12 > day = 20 > svn rev = 36812 > language = R > > Locale: > [EMAIL > PROTECTED];LC_NUMERIC=C;LC_TIME=en_US.ISO-8859-15;LC_COLLATE=en_US.ISO-8859-15;[EMAIL > > PROTECTED];LC_MESSAGES=en_US.ISO-8859-15;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C > > Search Path: > .GlobalEnv, package:methods, package:stats, package:graphics, > package:grDevices, package:utils, package:datasets, Autoloads, package:base > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- 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] Matrix inner product crashes on x86_64 (PR#8715)
On Mon, 27 Mar 2006, Prof Brian Ripley wrote: > Not reproducible for me (and do you really think that something as simple as > this would not have been found on x86_64 long before now?) > This is almost certainly caused by your use of an inappropriate external BLAS. > Something has probably been compiled for a different processor than the one > you are using, since illegal instructions are a compiler (not R) issue that I > have seen quite often on ix86 systems when this happened. > Use --without-blas when recompiling R and see if it then works. Thank you for the prompt reply. Disabling the external BLAS fixed the problem as you suspected. (As a minor curiosity, the problem was not caught by any tests ran by make check or make check-all -- but I do not presume here to speculate or guess whether the tests try out any such matrix calculations or not.). :) Thanks again, J. > > On Mon, 27 Mar 2006, [EMAIL PROTECTED] wrote: > > > > > Matrix inner product seems to crash R2.2.1 on a 64bit arch. > > More precisely, the crash happens atleast if the matrix is > > non-square. The bug can be reproduced (atleast here) with > > > > bash$ bin/R > > > X<-matrix(data=0,nrow=100,ncol=10); > > > mat<-X%*%t(X); > > Illegal instruction > > bash$ > > > > The crash doesnt happen if the matrix is specified square, > > e.g. 10x10. The underlying OS was > > > > Linux version 2.6.12-xeon-csl3 ([EMAIL PROTECTED]) (gcc version 3.4.5 > > 20050809 > > (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 SMP Wed Feb 22 18:34:17 EET 2006 > > > > and its running on Intel(R) Xeon(TM) MP CPU 3.66GHz. > > > > I configured R from the source tar.gz myself; each phase of > > "./configure --with-x=no ; make ; make install" > > passed without aborting on any errors. > > > > > > Cheers, > > J. > > > > --please do not edit the information below-- > > > > Version: > > platform = x86_64-unknown-linux-gnu > > arch = x86_64 > > os = linux-gnu > > system = x86_64, linux-gnu > > status = > > major = 2 > > minor = 2.1 > > year = 2005 > > month = 12 > > day = 20 > > svn rev = 36812 > > language = R > > > > Locale: > > [EMAIL PROTECTED];LC_NUMERIC=C;LC_TIME=en_US.ISO-8859-15;LC_COLLATE=en_US.IS > > O-8859-15;[EMAIL PROTECTED];LC_MESSAGES=en_US.ISO-8859-15;LC_PAPER=C;LC_N > > AME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C > > > > Search Path: > > .GlobalEnv, package:methods, package:stats, package:graphics, > > package:grDevices, package:utils, package:datasets, Autoloads, package:base > > > > __ > > 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
[Rd] sink(..., split=T) gives segmentation fault (PR#8716)
Full_Name: D Kreil
Version: R 2.2.1 (2005-12-20).
OS: Linux, Fedora FC4
Submission from: (NULL) (62.178.15.60)
sink("filename",split=T);
cat("sometext\n");
for (...) {
cat(some terms);
}
reproducibly gives a segmentation fault. No other problems with this
installation.
Removing the split=T fixes the crash.
uname -a gives:
Linux aton.boku.ac.at 2.6.15-1.1831_FC4smp #1 SMP Tue Feb 7 13:51:52 EST 2006
x86_64 x86_64 x86_64 GNU/Linux
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error once having applied (PR#8718)
Hi, people. Here is a transcript of a "R --vanilla" session: ==> R : Copyright 2005, The R Foundation for Statistical Computing Version 2.2.1 (2005-12-20 r36812) ISBN 3-900051-07-0 R est un logiciel libre livré sans AUCUNE GARANTIE. Vous pouvez le redistribuer sous certaines conditions. Tapez 'license()' ou 'licence()' pour plus de détails. R est un projet collaboratif avec de nombreux contributeurs. Tapez 'contributors()' pour plus d'information et 'citation()' pour la façon de le citer dans les publications. Tapez 'demo()' pour des démonstrations, 'help()' pour l'aide en ligne ou 'help.start()' pour obtenir l'aide au format HTML. Tapez 'q()' pour quitter R. > z = data.frame(a=0:9, b=10:19) > apply(z, 1, sum) 1 2 3 4 5 6 7 8 9 10 10 12 14 16 18 20 22 24 26 28 > apply(z, 1, '$', 'a') NULL > apply(z, 1, sum) Erreur dans sum(..., na.rm = na.rm) : 'mode' de l'argument incorrect ==< There are three explicit calls to "apply", one would expect the first and the third to yield similar results. They do indeed, if the second "apply" is not executed, or if '$' gets replaced by '[[' within it. So the second "apply", as written, may be hurting the R interpreter. --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 2 minor = 2.1 year = 2005 month = 12 day = 20 svn rev = 36812 language = R Locale: LC_CTYPE=fr_CA.UTF-8;LC_NUMERIC=C;LC_TIME=fr_CA.UTF-8;LC_COLLATE=fr_CA.UTF-8;LC_MONETARY=fr_CA.UTF-8;LC_MESSAGES=fr_CA.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix inner product crashes on x86_64 (PR#8715)
On Mon, 27 Mar 2006, Jussi T Lindgren wrote: > On Mon, 27 Mar 2006, Prof Brian Ripley wrote: > >> Not reproducible for me (and do you really think that something as simple as >> this would not have been found on x86_64 long before now?) >> This is almost certainly caused by your use of an inappropriate external >> BLAS. >> Something has probably been compiled for a different processor than the one >> you are using, since illegal instructions are a compiler (not R) issue that I >> have seen quite often on ix86 systems when this happened. >> Use --without-blas when recompiling R and see if it then works. > > Thank you for the prompt reply. Disabling the external BLAS fixed > the problem as you suspected. > > (As a minor curiosity, the problem was not caught by any tests > ran by make check or make check-all -- but I do not presume here > to speculate or guess whether the tests try out any such matrix > calculations or not.). :) They do. What the BLAS does will depend on the exact dimensions, so there will be very many paths through its code. > > > Thanks again, > J. > > >> >> On Mon, 27 Mar 2006, [EMAIL PROTECTED] wrote: >> >>> >>> Matrix inner product seems to crash R2.2.1 on a 64bit arch. >>> More precisely, the crash happens atleast if the matrix is >>> non-square. The bug can be reproduced (atleast here) with >>> >>> bash$ bin/R X<-matrix(data=0,nrow=100,ncol=10); mat<-X%*%t(X); >>> Illegal instruction >>> bash$ >>> >>> The crash doesnt happen if the matrix is specified square, >>> e.g. 10x10. The underlying OS was >>> >>> Linux version 2.6.12-xeon-csl3 ([EMAIL PROTECTED]) (gcc version 3.4.5 >>> 20050809 >>> (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 SMP Wed Feb 22 18:34:17 EET 2006 >>> >>> and its running on Intel(R) Xeon(TM) MP CPU 3.66GHz. >>> >>> I configured R from the source tar.gz myself; each phase of >>> "./configure --with-x=no ; make ; make install" >>> passed without aborting on any errors. >>> >>> >>> Cheers, >>> J. >>> >>> --please do not edit the information below-- >>> >>> Version: >>> platform = x86_64-unknown-linux-gnu >>> arch = x86_64 >>> os = linux-gnu >>> system = x86_64, linux-gnu >>> status = >>> major = 2 >>> minor = 2.1 >>> year = 2005 >>> month = 12 >>> day = 20 >>> svn rev = 36812 >>> language = R >>> >>> Locale: >>> [EMAIL PROTECTED];LC_NUMERIC=C;LC_TIME=en_US.ISO-8859-15;LC_COLLATE=en_US.IS >>> O-8859-15;[EMAIL PROTECTED];LC_MESSAGES=en_US.ISO-8859-15;LC_PAPER=C;LC_N >>> AME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C >>> >>> Search Path: >>> .GlobalEnv, package:methods, package:stats, package:graphics, >>> package:grDevices, package:utils, package:datasets, Autoloads, package:base >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> >> >> > > -- 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
[Rd] R 2.3.0 (alpha) on FreeBSD 6.1 fails make check-all
Hi Developers, The alpha, compiles successfully, but it is failing make check-all (on two seperate machines, both FreeBSD 6.1). Here is the version string: platform i386-unknown-freebsd6.1 arch i386 os freebsd6.1 system i386, freebsd6.1 status alpha major 2 minor 3.0 year 2006 month 03 day27 svn rev37584 language R version.string Version 2.3.0 alpha (2006-03-27 r37584) Here is the error message from make check-all comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...706c706 < [1] "Mean scaled difference: 0.0833" --- > [1] TRUE gmake[3]: *** [d-p-q-r-tests.Rout] Error 1 gmake[3]: Leaving directory `/usr/local/beta/R-alpha/tests' gmake[2]: *** [test-Specific] Error 2 gmake[2]: Leaving directory `/usr/local/beta/R-alpha/tests' gmake[1]: *** [test-all-basics] Error 1 gmake[1]: Leaving directory `/usr/local/beta/R-alpha/tests' gmake: *** [check-all] Error 2 I have checked d-p-q-r-tests.Rout.fail for any obvious problems - I found some warnings, viz. > pgamma(1,Inf,scale=Inf) == 0 [1] TRUE > ## Also pgamma(Inf,Inf) == 1 for which NaN was slightly more appropriate > all(is.nan(c(pgamma(Inf, 1,scale=Inf), + pgamma(Inf,Inf,scale=Inf [1] TRUE Warning messages: 1: NaNs produced in: pgamma(q, shape, scale, lower.tail, log.p) 2: NaNs produced in: pgamma(q, shape, scale, lower.tail, log.p) > x0 <- -2 * 10^-c(22,10,7,5) > stopifnot(pbinom(x0, size = 3, prob = 0.1) == 0, + dbinom(x0, 3, 0.1) == 0) # d*() warns about non-integer Warning messages: 1: non-integer x = -0.00 2: non-integer x = -0.20 > ## very small negatives were rounded to 0 in R 2.2.1 and earlier > I hope that this is helpful. Thanks are due to Peter Dalgaard for guidance. So, thanks Peter :). Cheers Andrew -- Andrew Robinson Department of Mathematics and StatisticsTel: +61-3-8344-9763 University of Melbourne, VIC 3010 Australia Fax: +61-3-8344-4599 Email: [EMAIL PROTECTED] http://www.ms.unimelb.edu.au __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
