Build directory path saved in Meta/hsearch.rds

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Build directory path saved in Meta/hsearch.rds

José Matos-2
Hi,
  in Fedora Extras we build R packages to a temporary directory. The
relevant section in
the spec file is this:

%build
cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library

It works. :-)

We noticed one problem though (I will assume working on ix86 here) the
temporary build path is saved in
/usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.

To see this is enough to run strings over these file.

Is this a security concern? Does R uses this path in any way?

In case the answer is yes, it is safe to run sed over this file and do
a textual replacement?

Thanks and best regards,
--
José Matos

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build directory path saved in Meta/hsearch.rds

José Matos-2
On 03/03/06, José Matos <[hidden email]> wrote:

> Hi,
>   in Fedora Extras we build R packages to a temporary directory. The
> relevant section in
> the spec file is this:
>
> %build
> cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library
>
> It works. :-)
>
> We noticed one problem though (I will assume working on ix86 here) the
> temporary build path is saved in
> /usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.

  Searching a little bit more I see that Peter Daalgard came to the
same conclusion one month ago:
https://stat.ethz.ch/pipermail/r-help/2006-February/086069.html

> To see this is enough to run strings over these file.
>
> Is this a security concern? Does R uses this path in any way?
>
> In case the answer is yes, it is safe to run sed over this file and do
> a textual replacement?
>
> Thanks and best regards,
> --
> José Matos
>

--
José Abílio

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build directory path saved in Meta/hsearch.rds

Dirk Eddelbuettel

On 3 March 2006 at 23:17, José Matos wrote:
| On 03/03/06, José Matos <[hidden email]> wrote:
| > Hi,
| >   in Fedora Extras we build R packages to a temporary directory. The
| > relevant section in
| > the spec file is this:
| >
| > %build
| > cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library
| >
| > It works. :-)
| >
| > We noticed one problem though (I will assume working on ix86 here) the
| > temporary build path is saved in
| > /usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.
|
|   Searching a little bit more I see that Peter Daalgard came to the
| same conclusion one month ago:
| https://stat.ethz.ch/pipermail/r-help/2006-February/086069.html

And I guess you also saw that he called that harmless, right?

We have building packages like this 'forever' under Debian and yet to have a
problem with it:

edd@basebud:~> strings /usr/lib/R/site-library/*/Meta/*.rds | grep -c buildd
5154

That 5154 occurrences of the string buildd showing that the package was built
in a Debian autobuilder.  

| > To see this is enough to run strings over these file.
| >
| > Is this a security concern? Does R uses this path in any way?

Why would this have security implications?  As others have said, the main
thing is $R_HOME set in the R shell script (and now to a lesser extent the
locations for the doc/, include/, and share/ directories which are allowed to
be somewhere other than directly under $R_HOME if you so desire [ and we do,
slowly, as there may be advantages to eventual convergence towards Linux FHS
standards ] ).

| > In case the answer is yes, it is safe to run sed over this file and do
| > a textual replacement?

I'd treat that as an empirical exercise :)  Maybe you can even cook up a
patch that may one day make it into being called by 'make install' ?

Dirk

--
Hell, there are no rules here - we're trying to accomplish something.
                                                  -- Thomas A. Edison

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build directory path saved in Meta/hsearch.rds

Brian Ripley
In reply to this post by José Matos-2
On Fri, 3 Mar 2006, José Matos wrote:

> On 03/03/06, José Matos <[hidden email]> wrote:
>> Hi,
>>   in Fedora Extras we build R packages to a temporary directory. The
>> relevant section in
>> the spec file is this:
>>
>> %build
>> cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library
>>
>> It works. :-)
>>
>> We noticed one problem though (I will assume working on ix86 here) the
>> temporary build path is saved in
>> /usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.
>
>  Searching a little bit more I see that Peter Daalgard came to the
> same conclusion one month ago:
> https://stat.ethz.ch/pipermail/r-help/2006-February/086069.html
Yes, and his conclusion holds as well.

Please explain what the problem is.  The first element of the object saved
in hsearch.rds is a data frame with a column LibPath.  This is not used
by help.search() after installation.

>> To see this is enough to run strings over these file.
>>
>> Is this a security concern?

Why should there be any security issues about a non-existent path?

>> Does R uses this path in any way?

Peter was referring to packages installed with R.  If they were used, no
binary installation of R would work, so I presume they are not used.

>> In case the answer is yes, it is safe to run sed over this file and do
>> a textual replacement?

Not safe: the string lengths are encoded in the file.

>>
>> Thanks and best regards,
>> --
>> José Matos
>>
>
> --
> José Abílio
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley,                  [hidden email]
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, UK                Fax:  +44 1865 272595
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build directory path saved in Meta/hsearch.rds

Brian Ripley
I've made two changes for R 2.3.0

1) as the LibPath is not actually used, it is recorded as "".  (For
compatibility we don't want to remove the field.)  Since it was returned
but not printed by help.search(), the actual installed path is returned
instead.  (Given that the return format of help.search is undocumented, I
don't see how anyone could have made use of it without realizing it was
subject to guesswork and to change.)

2) hsearch.rds could usefully be stored in compressed format, and so will
be.

On Sat, 4 Mar 2006, Prof Brian Ripley wrote:

> On Fri, 3 Mar 2006, José Matos wrote:
>
>> On 03/03/06, José Matos <[hidden email]> wrote:
>>> Hi,
>>>   in Fedora Extras we build R packages to a temporary directory. The
>>> relevant section in
>>> the spec file is this:
>>>
>>> %build
>>> cd ..; R CMD INSTALL %{packname} -l %{buildroot}%{_libdir}/R/library
>>>
>>> It works. :-)
>>>
>>> We noticed one problem though (I will assume working on ix86 here) the
>>> temporary build path is saved in
>>> /usr/lib/R/library/*/Meta/hsearch.rds, i.e. for each package.
>>
>>  Searching a little bit more I see that Peter Daalgard came to the
>> same conclusion one month ago:
>> https://stat.ethz.ch/pipermail/r-help/2006-February/086069.html
>
> Yes, and his conclusion holds as well.
>
> Please explain what the problem is.  The first element of the object saved in
> hsearch.rds is a data frame with a column LibPath.  This is not used
> by help.search() after installation.
>
>>> To see this is enough to run strings over these file.
>>>
>>> Is this a security concern?
>
> Why should there be any security issues about a non-existent path?
>
>>> Does R uses this path in any way?
>
> Peter was referring to packages installed with R.  If they were used, no
> binary installation of R would work, so I presume they are not used.
>
>>> In case the answer is yes, it is safe to run sed over this file and do
>>> a textual replacement?
>
> Not safe: the string lengths are encoded in the file.
>
>>>
>>> Thanks and best regards,
>>> --
>>> José Matos
>>>
>>
>> --
>> José Abílio
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
--
Brian D. Ripley,                  [hidden email]
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, UK                Fax:  +44 1865 272595
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Build directory path saved in Meta/hsearch.rds

José Matos-2
On 04/03/06, Prof Brian Ripley <[hidden email]> wrote:

> I've made two changes for R 2.3.0
>
> 1) as the LibPath is not actually used, it is recorded as "".  (For
> compatibility we don't want to remove the field.)  Since it was returned
> but not printed by help.search(), the actual installed path is returned
> instead.  (Given that the return format of help.search is undocumented, I
> don't see how anyone could have made use of it without realizing it was
> subject to guesswork and to change.)
>
> 2) hsearch.rds could usefully be stored in compressed format, and so will
> be.

  I would like to thank you and Dirk for your answers (and Peter
Daalgard FWIW :-).

My concern was that R could use that path in some way.

Usually this is not a problem because as Brian clearly told that path
will be inexistent, the problem would exist if this temporary path
could be exploited maliciously to inject code into R. I hope that
these concerns don't sound too far fetched since sometimes the
temporary directories are world writable.

  Thank you for the change, I am glad to see that this will be
addressed for 2.3.

  Best regards,
--
José Abílio

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel