From simon.urbanek at r-project.org  Wed Aug  3 21:37:37 2011
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 3 Aug 2011 15:37:37 -0400
Subject: [Rd] example package for devel newcomers
In-Reply-To: <201108031419.42767@spsconsultoria.com>
References: <201107311845.50264@spsconsultoria.com>
	<201108030228.39854@spsconsultoria.com>
	<66771A9D-6044-40B8-AAC1-BCDCD581EA89@r-project.org>
	<201108031419.42767@spsconsultoria.com>
Message-ID: <62071B9A-7AD9-411D-B2A7-D3FB8081AB08@r-project.org>

Alexandre,

On Aug 3, 2011, at 1:19 PM, Alexandre Aguiar wrote:

> Simon,
> 
> Em Quarta 03 Agosto 2011, voc? escreveu:
>> In that light you may want to explain why you need 2-5 since the
>> easiest way is to simply link to libphp.
> 
> Resources accessible to libphp through apache are limited by ssytem 
> configurations. With libphp fully available to every user there are 
> potential problems. For instance, snooping into system configurations 
> especially in networked applications or a maliciously hacked user 
> compiled libphp.
> 
> About 2: the need for configuration changes tailored to local 
> restrictions. Have convinced myself that building R_CMethodDef and 
> R_CallMethodDef dinamically will be better. For instance, in 
> a "precompiled scenario" php functions that make use of db4 libraries 
> would cause a crash if those libraries are not available.
> 
> About 5: a user could redefine parameters to "reuse" libphp directly 
> using "good guy" loading mechanism of Rphp. While Rphp itself would be 
> harmless, loading its library would make libphp available within the R 
> process. R might be used as unsuspected hacking tool.
> 
> I mean, exporting functions from libphp can be good or evil and 
> potentially harmful without the limits imposed by apache and with the 
> potential use of a hacked libphp.
> 

To be honest I don't understand what you mean at all. Registering .C/.Call/... symbols in R is just a convenience - mostly for argument checking on the R side. There is nothing stopping users from calling any C entry point, because R allows users to load any dynamic object they want and call any symbol therein - so they can simply load libphp directly without any trouble. The moment you include R you have access to everything. I also don't understand your point with db4, because the registrations you mention are for R wrappers, not for native API, so you can't call any function in libphp directly so you have to abstract the functionality anyway (let's say throwing an error if the capability is not included). I suspect either I misunderstand what you want or you misunderstand the symbol registration.


>> As for 7, R uses mingw gcc (see Windows FAQ, we provide all the tools)
>> so as long as php can be built that way there should due no issues.
> 
> I'll check that out asap.
> 
> Regarding recursion and stack size, I have been assured by a php developer 
> that it currently is not a concern. Have also found that a recursion 
> problem with libpcre (used by libphp) has been solved.
> 
> In a phrase: problems I foresee are related to deployment of libphp and 
> potential security breaches.
> 

Well, the moment R is in the mix, there is no access control so that seems like worrying about a crack while the door is open ;). But, again, I may not quite understand what you really mean.

Cheers,
Simon



[Rd] example package for devel newcomers
Simon Urbanek