Bug 16725 - symlinks in package library
Summary: symlinks in package library
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: Low-level (show other bugs)
Version: R-devel (trunk)
Hardware: Other Linux
: P5 minor
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2016-02-23 13:29 UTC by Jeroen Ooms
Modified: 2016-11-13 16:17 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeroen Ooms 2016-02-23 13:29:10 UTC
When a package library on Linux contains symlinks, update.packages() gives an unexpected error "not a legal package name". Below a reproducible example on Ubuntu 14.04 (but it seems fine on OS-X)

dir.create(tmplib1 <- tempfile())
dir.create(tmplib2 <- tempfile())
install.packages("https://cran.r-project.org/src/contrib/Archive/MASS/MASS_7.3-44.tar.gz",
  repos = NULL, lib = tmplib1)
file.symlink(file.path(tmplib1, "MASS"), file.path(tmplib2, "MASS"))
update.packages(tmplib2, ask= FALSE)
Comment 1 Jeroen Ooms 2016-03-01 14:18:15 UTC
The problem is the `is_subdir` function in tools/install.R [1] which is used to check against malicious package names:

    is_subdir <- function(dir, parent)
        normalizePath(parent) == normalizePath(file.path(dir, ".."))

When `dir` (the package directory) is actually a symlink to another library, it gets resolved by normalizePath and hence is no longer a subdir of `parent`.

[1] https://github.com/wch/r-source/blob/tags/R-3-2-3/src/library/tools/R/install.R#L199-L204
Comment 2 Martin Maechler 2016-07-22 07:09:40 UTC
(In reply to Jeroen from comment #1)
> The problem is the `is_subdir` function in tools/install.R [1] which is used
> to check against malicious package names:
> 
>     is_subdir <- function(dir, parent)
>         normalizePath(parent) == normalizePath(file.path(dir, ".."))
> 
> When `dir` (the package directory) is actually a symlink to another library,
> it gets resolved by normalizePath and hence is no longer a subdir of
> `parent`.
> 
> [1]
> https://github.com/wch/r-source/blob/tags/R-3-2-3/src/library/tools/R/
> install.R#L199-L204

In the mean time, I have committed a change to  is_subdir()   to R-devel only,

hence the bug is considered fixed by me.
There is the issue that R currently *removes* the symlink to a directory and puts the package directory right there,  and I agree that it is desirable to *change* that.
If you want please open a new issue for that .

Further note my R-devel e-mail
      https://stat.ethz.ch/pipermail/r-devel/2016-July/072919.html
which concludes a newer thread on this issue.
Comment 3 Martin Maechler 2016-11-13 16:17:56 UTC
(In reply to Martin Maechler from comment #2)
> (In reply to Jeroen from comment #1)
> > The problem is the `is_subdir` function in tools/install.R [1] which is used
> > to check against malicious package names:
> > 
> >     is_subdir <- function(dir, parent)
> >         normalizePath(parent) == normalizePath(file.path(dir, ".."))
> > 
> > When `dir` (the package directory) is actually a symlink to another library,
> > it gets resolved by normalizePath and hence is no longer a subdir of
> > `parent`.
> > 
> > [1]
> > https://github.com/wch/r-source/blob/tags/R-3-2-3/src/library/tools/R/
> > install.R#L199-L204
> 
> In the mean time, I have committed a change to  is_subdir()   to R-devel
> only,
> 
> hence the bug is considered fixed by me.
> There is the issue that R currently *removes* the symlink to a directory and
> puts the package directory right there,  and I agree that it is desirable to
> *change* that.
> If you want please open a new issue for that .
> 
> Further note my R-devel e-mail
>       https://stat.ethz.ch/pipermail/r-devel/2016-July/072919.html
> which concludes a newer thread on this issue.

Replying to myself:

From a use case, just now, I indeed think, the R-devel behavior is fine.
Removing the sym.link and installing (a "real" package directory) is desired in my use case at least.

And as indeed that use case was with R-patched (and we have not seen any problems with the change in R-devel), I'm now porting the fix to 'R-patched', i.e., 'R 3.3.2 patched'.