Re: [Rd] locking down R

2013-05-20 Thread Barry Rowlingson 
On Sun, May 19, 2013 at 7:16 PM, Ben Bolker  wrote:
>
>The workstations have no access to external networks,
> nor to external media (thumb drives etc.) [information transfer to the
> outside world is via shared drives that can be accessed by
> administrators with network access].
>
> * I stipulate that (1) the security policies don't make sense,

 Correct. If the machines aren't on an external network and have no
removable media then this isn't about security from the outside
hacker, its about trust. The organisation does not trust YOU.

(2)
> allowing users access to arbitrary shell commands should _not_ represent
> a security risk on a well-administered, modern operating system (they're
> running WinXP),

 When does WinXP go out of support? Even so, the PC isn't on the
network right? So what's the security issue? Doesn't make sense. You
can't stomp on other people's files. Would it matter if you could
accidentally see other people's files because they set permissions
loosely? How compartmentalised are the projects?

 (3) R probably offers many other avenues for system
> access to a malicious user, even in the absence of shell access,
> compilers, etc..

 The 'malicious user' here is on the inside. The only way to get on
the machine is to be physically there? Then a malicious user can only
be a trusted user gone bad. A sufficiently malicious user with
hardware access can (nearly) always break the thing open and get at
the data (even if it comes down to reading data lines with a tap to
get at unencrypted streams). Tell the security guys they need to lock
the PCs up in a room and provide thin client access over a secure
private network at once. Enjoy your new Windows Client Access License
costs.

 Glad I don't work for someone like that.

Barry

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R CMD check: unknown option ‘--outdir==RCHECK’

2013-05-20 Thread Matthieu Stigler 
Dear R devel

I am experiencing a problem using R CMD check. I tried to specify the
argument outdir, but get every time the error message:
Warning: unknown option ‘--outdir==RCHECK’

This happens both on R 2.15.2 Linux, as well as R 3.0.1 Windows, with
latest Rtools. Is it just that I am not passing the argument the right way,
or is there an issue with R CMD check?

I tried to write the argument in many differents ways, but it always fails.
Standard way I tried is:
$ R CMD check --outdir="RCHECK"  pkg.tar.gz
Warning: unknown option ‘--outdir=RCHECK'

Thanks for your advices!

Matthieu Stigler

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check: unknown option ‘--outdir==RCHECK’

2013-05-20 Thread Duncan Murdoch 

On 13-05-20 6:05 AM, Matthieu Stigler wrote:

Dear R devel

I am experiencing a problem using R CMD check. I tried to specify the
argument outdir, but get every time the error message:
Warning: unknown option ‘--outdir==RCHECK’

This happens both on R 2.15.2 Linux, as well as R 3.0.1 Windows, with
latest Rtools. Is it just that I am not passing the argument the right way,
or is there an issue with R CMD check?

I tried to write the argument in many differents ways, but it always fails.
Standard way I tried is:
$ R CMD check --outdir="RCHECK"  pkg.tar.gz
Warning: unknown option ‘--outdir=RCHECK'


There are a couple of bugs here.  First, a simple typo: the code is 
looking for --output=RCHECK, not --outdir=RCHECK.  But if you use 
--output, you'll likely get an error saying you can't change directory 
to it.


I'll take a look at both.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD check: unknown option ‘--outdir==RCHECK’

2013-05-20 Thread Duncan Murdoch 

On 13-05-20 6:34 AM, Duncan Murdoch wrote:

On 13-05-20 6:05 AM, Matthieu Stigler wrote:

Dear R devel

I am experiencing a problem using R CMD check. I tried to specify the
argument outdir, but get every time the error message:
Warning: unknown option ‘--outdir==RCHECK’

This happens both on R 2.15.2 Linux, as well as R 3.0.1 Windows, with
latest Rtools. Is it just that I am not passing the argument the right way,
or is there an issue with R CMD check?

I tried to write the argument in many differents ways, but it always fails.
Standard way I tried is:
$ R CMD check --outdir="RCHECK"  pkg.tar.gz
Warning: unknown option ‘--outdir=RCHECK'


There are a couple of bugs here.  First, a simple typo: the code is
looking for --output=RCHECK, not --outdir=RCHECK.  But if you use
--output, you'll likely get an error saying you can't change directory
to it.

I'll take a look at both.


Sorry, only one bug, misleading help text.

The help text says

  -o, --outdir=DIR  directory used for logfiles, R output, etc.
(default is 'pkg.Rcheck' in current directory,
where 'pkg' is the name of the package checked)

but in fact DIR is the location where pkg.Rcheck will be placed.  It 
needs to exist in advance.  (This allows multiple packages to be checked 
in one command.  I've never used multiple checks at once, but it looks 
like something CRAN might need to do.)


I'll fix this by changing the help text, not the behaviour.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] locking down R

2013-05-20 Thread Ben Bolker 
On 13-05-20 04:42 AM, Barry Rowlingson wrote:
> On Sun, May 19, 2013 at 7:16 PM, Ben Bolker  wrote:
>>
>> The workstations have no access to external networks,
>> nor to external media (thumb drives etc.) [information transfer to the
>> outside world is via shared drives that can be accessed by
>> administrators with network access].
>>
>> * I stipulate that (1) the security policies don't make sense,
> 
>  Correct. If the machines aren't on an external network and have no
> removable media then this isn't about security from the outside
> hacker, its about trust. The organisation does not trust YOU.
> 
> (2)
>> allowing users access to arbitrary shell commands should _not_ represent
>> a security risk on a well-administered, modern operating system (they're
>> running WinXP),
> 
>  When does WinXP go out of support? Even so, the PC isn't on the
> network right? So what's the security issue? Doesn't make sense. You
> can't stomp on other people's files. Would it matter if you could
> accidentally see other people's files because they set permissions
> loosely? How compartmentalised are the projects?

   That is indeed one of the major concerns.  The administrators could
certainly lock the file access down more than they have (permissions are
restricted, but I have information about the existence of lots of
directories that I don't have permission to access: the system would
probably be more secure if I couldn't even see the top level of these
directories).

>  (3) R probably offers many other avenues for system
>> access to a malicious user, even in the absence of shell access,
>> compilers, etc..
> 
>  The 'malicious user' here is on the inside. The only way to get on
> the machine is to be physically there? Then a malicious user can only
> be a trusted user gone bad. A sufficiently malicious user with
> hardware access can (nearly) always break the thing open and get at
> the data (even if it comes down to reading data lines with a tap to
> get at unencrypted streams). Tell the security guys they need to lock
> the PCs up in a room and provide thin client access over a secure
> private network at once. Enjoy your new Windows Client Access License
> costs.
> 
>  Glad I don't work for someone like that.

  For what it's worth, (1) the people I deal with directly are very
nice, but not technically astute; the problem is more one of a large
bureaucracy covering its ass in some nonsensical ways; (2) this is only
a tiny component of my work.  If I get really frustrated with this I can
just drop it.

  I agree with your analysis of the real security situation, more or
less. (The PCs are pretty secure physically; it would be pretty hard to
break into the boxes without being noticed ...), but I think this
 is  a pretty good analogy for the kind of
argument I could get into here.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] locking down R

2013-05-20 Thread Ben Bolker 
On 13-05-19 06:08 PM, R. Michael Weylandt wrote:
> On Sun, May 19, 2013 at 7:16 PM, Ben Bolker  wrote:
>>
>>   Is anyone on this list aware of discussions about locking down/securing R?
>>
>>   My colleagues and I are working with health statistics in an office
>> that disallows many useful tools (e.g. emacs, vim, perl, make) on the
>> grounds that they represent a security risk.  We are considering pushing
>> back, but we are worried that if we attract the attention of the Powers
>> That Be to the reality that R allows execution of arbitrary shell
>> commands, they will then disallow the use of R (SAS and Stata are our
>> other optiona). It might be useful to be able to give them options for
>> securing R.
>>
>>   Possibly useful information:
>>
>> * the office allows use of SAS (and Stata, MLWiN, etc.) but uses the
>> NOXCMD specification to prevent shell access from within SAS. They also
>> disallow access to the Windows shell (in the current configuration,
>> shell() works fine from within R, but we think this may have escaped
>> their notice ...) The workstations have no access to external networks,
>> nor to external media (thumb drives etc.) [information transfer to the
>> outside world is via shared drives that can be accessed by
>> administrators with network access].
>>
>> * I stipulate that (1) the security policies don't make sense, (2)
>> allowing users access to arbitrary shell commands should _not_ represent
>> a security risk on a well-administered, modern operating system (they're
>> running WinXP), (3) R probably offers many other avenues for system
>> access to a malicious user, even in the absence of shell access,
>> compilers, etc..
> 
> If you really mean a "modern operating system"... ;-)
> 
> http://arxiv.org/abs/1303.4808
> 
> Cheers,
> MW

  Interesting, of course, but WinXP is the target OS (unless your point
is that people are worrying about this even on Linux).  (Another point
not mentioned previously is that users have to sign a fairly serious
confidentiality oath to get access to this system in the first place,
which presumably includes an implied "I won't hack the system" clause ...)

  RAppArmor is an interesting idea, as is sandboxR (mentioned in the
paper); I also looked up Sandboxie (a Windows program for sandboxing).
I don't think any of these will really solve the problem, though ...

 thanks
   Ben Bolker

> 
>>
>> * I suspect the answer given here will be "if you really want to secure
>> R, run it within a standard restricted-access shell (e.g. chroot on a
>> Linux system)".  If anyone has experience of 'locking down' R on Windows
>> (XP) in a sensitive environment, I'd be curious about the details.
>>
>>  thanks
>>   Ben Bolker
>>
>> __
>> 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] Accessing element of a vector using a function (as opposed to macro)

2013-05-20 Thread Saptarshi Guha 
Hello,

I have a double vector, x. I can access the i'th element as

REAL(x)[i]

Is there a function for this? I know i can write my own, but was seeing if
one already exists. I did check Rinternals.h but didn't see one.

Cheers
Saptarshi

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Accessing i'th element of a vector without using a macro

2013-05-20 Thread Saptarshi Guha 
Hello,

I have a double vector, x. I can access the i'th element as

REAL(x)[i]

Is there a function for this? I know i can write my own, but was
seeing if one already exists. I did check Rinternals.h but didn't see
one.

Cheers
Saptarshi

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accessing i'th element of a vector without using a macro

2013-05-20 Thread Gabriel Becker 
Saptarshi,

When I need to repeatedly access data from a an R vector in C I typically
just create a pointer to the data and just use that.

double *xdat = REAL(x);
xdat[i]; //repeat as necessary

This is also displayed in 5.9.4 of the R extensions manual.

Is there a reason this wouldn't work for your usecase? What exactly is it
that you want to do?

~G




On Mon, May 20, 2013 at 9:56 AM, Saptarshi Guha wrote:

> Hello,
>
> I have a double vector, x. I can access the i'th element as
>
> REAL(x)[i]
>
> Is there a function for this? I know i can write my own, but was
> seeing if one already exists. I did check Rinternals.h but didn't see
> one.
>
> Cheers
> Saptarshi
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Accessing i'th element of a vector without using a macro

2013-05-20 Thread Saptarshi Guha 
Exactly, that is what i use. I intend to do the operation using an FFI
library(i't s just a proof of concept, and there well might be
performance hits)
If such a function doesn't exist in libR.so, then i can write one.

Regards
Saptarshi


On Mon, May 20, 2013 at 10:03 AM, Gabriel Becker  wrote:
> Saptarshi,
>
> When I need to repeatedly access data from a an R vector in C I typically
> just create a pointer to the data and just use that.
>
> double *xdat = REAL(x);
> xdat[i]; //repeat as necessary
>
> This is also displayed in 5.9.4 of the R extensions manual.
>
> Is there a reason this wouldn't work for your usecase? What exactly is it
> that you want to do?
>
> ~G
>
>
>
>
> On Mon, May 20, 2013 at 9:56 AM, Saptarshi Guha 
> wrote:
>>
>> Hello,
>>
>> I have a double vector, x. I can access the i'th element as
>>
>> REAL(x)[i]
>>
>> Is there a function for this? I know i can write my own, but was
>> seeing if one already exists. I did check Rinternals.h but didn't see
>> one.
>>
>> Cheers
>> Saptarshi
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] locking down R

2013-05-20 Thread Tim Triche, Jr. 
short of running everything in a VM, I'd have to guess you're hosed...  I
don't understand how an operating system with internals as opaque as
Windows (NT/2000/beyond, not just the old DOS-based garbage) could ever be
considered secure for intensive computation, but that seems beside the
point.  You could perhaps recompile R, leaving out the bits offensive to
management, and use that... ?

If they will let you run in a VM, on the other hand, RAppArmor could
satisfy most of these demands in a hurry.



On Mon, May 20, 2013 at 8:12 AM, Ben Bolker  wrote:

> On 13-05-19 06:08 PM, R. Michael Weylandt wrote:
> > On Sun, May 19, 2013 at 7:16 PM, Ben Bolker  wrote:
> >>
> >>   Is anyone on this list aware of discussions about locking
> down/securing R?
> >>
> >>   My colleagues and I are working with health statistics in an office
> >> that disallows many useful tools (e.g. emacs, vim, perl, make) on the
> >> grounds that they represent a security risk.  We are considering pushing
> >> back, but we are worried that if we attract the attention of the Powers
> >> That Be to the reality that R allows execution of arbitrary shell
> >> commands, they will then disallow the use of R (SAS and Stata are our
> >> other optiona). It might be useful to be able to give them options for
> >> securing R.
> >>
> >>   Possibly useful information:
> >>
> >> * the office allows use of SAS (and Stata, MLWiN, etc.) but uses the
> >> NOXCMD specification to prevent shell access from within SAS. They also
> >> disallow access to the Windows shell (in the current configuration,
> >> shell() works fine from within R, but we think this may have escaped
> >> their notice ...) The workstations have no access to external networks,
> >> nor to external media (thumb drives etc.) [information transfer to the
> >> outside world is via shared drives that can be accessed by
> >> administrators with network access].
> >>
> >> * I stipulate that (1) the security policies don't make sense, (2)
> >> allowing users access to arbitrary shell commands should _not_ represent
> >> a security risk on a well-administered, modern operating system (they're
> >> running WinXP), (3) R probably offers many other avenues for system
> >> access to a malicious user, even in the absence of shell access,
> >> compilers, etc..
> >
> > If you really mean a "modern operating system"... ;-)
> >
> > http://arxiv.org/abs/1303.4808
> >
> > Cheers,
> > MW
>
>   Interesting, of course, but WinXP is the target OS (unless your point
> is that people are worrying about this even on Linux).  (Another point
> not mentioned previously is that users have to sign a fairly serious
> confidentiality oath to get access to this system in the first place,
> which presumably includes an implied "I won't hack the system" clause ...)
>
>   RAppArmor is an interesting idea, as is sandboxR (mentioned in the
> paper); I also looked up Sandboxie (a Windows program for sandboxing).
> I don't think any of these will really solve the problem, though ...
>
>  thanks
>Ben Bolker
>
> >
> >>
> >> * I suspect the answer given here will be "if you really want to secure
> >> R, run it within a standard restricted-access shell (e.g. chroot on a
> >> Linux system)".  If anyone has experience of 'locking down' R on Windows
> >> (XP) in a sensitive environment, I'd be curious about the details.
> >>
> >>  thanks
> >>   Ben Bolker
> >>
> >> __
> >> 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
>



-- 
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Objects created by more than one data call?

2013-05-20 Thread Spencer Graves 

Hello, All:


  If I use LazyData with the Ecdat package on R-Forge, "R CMD 
check" reports "no visible binding for global variable 
'nonEnglishNames'", where 'nonEnglishNames' is a dataset in Ecdat used 
as the default argument for a function.  With LazyData, that NOTE 
disappears.  However, then I get, "Warning: objects 'Hstarts', 
'Hstarts', 'MedExp' are created by more than one data call".



  What do you suggest I do to fix this problem?


  Thanks,
  Spencer Graves


> sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

other attached packages:
[1] Ecdat_0.2-3

loaded via a namespace (and not attached):
[1] tools_3.0.0

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Objects created by more than one data call?

2013-05-20 Thread Prof Brian Ripley 

On 21/05/2013 00:12, Spencer Graves wrote:

Hello, All:


   If I use LazyData with the Ecdat package on R-Forge, "R CMD
check" reports "no visible binding for global variable
'nonEnglishNames'", where 'nonEnglishNames' is a dataset in Ecdat used
as the default argument for a function.  With LazyData, that NOTE
disappears.  However, then I get, "Warning: objects 'Hstarts',
'Hstarts', 'MedExp' are created by more than one data call".


   What do you suggest I do to fix this problem?


Not create the objects in more than one data() call.

Check what each of your data() calls produces.




   Thanks,
   Spencer Graves


 > sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

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

other attached packages:
[1] Ecdat_0.2-3

loaded via a namespace (and not attached):
[1] tools_3.0.0

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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