/etc/R/Renviron doesn't set R_LIBS_USER anymore

| Hi
| 
| An upgrade to R 3.4.1 on Ubuntu removed the default setting of 
| R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? Thanks.

Pretty much exactly what I told you in person last week :)

- idea is to prefer /usr/local/lib/R/site-library/
- multi-user more important than per-user

Also see https://bugs.debian.org/866768

The transition may be too harsh though. I did not consider the possibility of
/usr/local/lib/R/site-library/ *not* being writeable.  So what I could do is
to re-add the per-user directory as a fall-back after the preferred
/usr/local/lib/R/site-library.

Dirk

http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On 2 July 2017 at 21:39, Kirill M?ller wrote:
| Hi
|
| An upgrade to R 3.4.1 on Ubuntu removed the default setting of
| R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? Thanks.

Pretty much exactly what I told you in person last week :)

- idea is to prefer /usr/local/lib/R/site-library/
- multi-user more important than per-user

Also see https://bugs.debian.org/866768

The transition may be too harsh though. I did not consider the possibility of
/usr/local/lib/R/site-library/ *not* being writeable.  So what I could do is
to re-add the per-user directory as a fall-back after the preferred
/usr/local/lib/R/site-library.

Thanks. The site-library is owned by root/staff on my system, and my 
user isn't member of the staff group (Ubuntu 17.04). I'm not sure how 
this looks on a factory-fresh install, but IMO users should be able to 
just use install.packages().


-Kirill

Dirk

| > | Hi
| > |
| > | An upgrade to R 3.4.1 on Ubuntu removed the default setting of
| > | R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? Thanks.
| >
| > Pretty much exactly what I told you in person last week :)
| >
| > - idea is to prefer /usr/local/lib/R/site-library/
| > - multi-user more important than per-user
| >
| > Also see https://bugs.debian.org/866768
| >
| > The transition may be too harsh though. I did not consider the possibility of
| > /usr/local/lib/R/site-library/ *not* being writeable.  So what I could do is
| > to re-add the per-user directory as a fall-back after the preferred
| > /usr/local/lib/R/site-library.
| Thanks. The site-library is owned by root/staff on my system, and my 
| user isn't member of the staff group (Ubuntu 17.04). I'm not sure how 
| this looks on a factory-fresh install, but IMO users should be able to 
| just use install.packages().

You should (as the local admin) set up appropriate groups and policies.

In the simplest case, one addgroup would do.

Worst case you can also

  i)   wrap sudo around the installation step,
  ii)  make the directory world-writeable or
  iii) set R_LIBS_USER in the *.site files.

I still feel (quite strongly) that this policy is the best, I do also see
that the implementation may not be ideal -- not running install.packages()
well is a bit of a, err, "setback".  Maybe I need to add it again at the end
of .libPath() ?

Dirk

| 
| 
| -Kirill
| 
| > Dirk
| >
|

http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On 2 July 2017 at 23:24, Kirill M?ller wrote:
| On 02.07.2017 22:01, Dirk Eddelbuettel wrote:
| > On 2 July 2017 at 21:39, Kirill M?ller wrote:
| > | Hi
| > |
| > | An upgrade to R 3.4.1 on Ubuntu removed the default setting of
| > | R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? 
Thanks.
| >
| > Pretty much exactly what I told you in person last week :)
| >
| > - idea is to prefer /usr/local/lib/R/site-library/
| > - multi-user more important than per-user
| >
| > Also see https://bugs.debian.org/866768
| >
| > The transition may be too harsh though. I did not consider the
possibility of
| > /usr/local/lib/R/site-library/ *not* being writeable.  So what I 
could do is
| > to re-add the per-user directory as a fall-back after the preferred
| > /usr/local/lib/R/site-library.
| Thanks. The site-library is owned by root/staff on my system, and my
| user isn't member of the staff group (Ubuntu 17.04). I'm not sure how
| this looks on a factory-fresh install, but IMO users should be able 
to
| just use install.packages().

You should (as the local admin) set up appropriate groups and policies.

In the simplest case, one addgroup would do.

While we are in this discussion, I would like to add that admins should 
be aware of the fact that adding a user to the "staff" group gives a lot 
of power and responsibility to that user, such a user can add 
executables to /usr/local/bin which is per default in the PATH of every 
user on the system. These binaries may override those in /usr/bin [1]. 
This is not necessary for R users that just want to install packages 
system-wide.

Shouldn't we recommend a dedicated group for installing R packages in 
order to avoid these security implications?

[1] https://wiki.debian.org/SystemGroups

Cheers,

Johannes

| > | > | Hi
| > | > |
| > | > | An upgrade to R 3.4.1 on Ubuntu removed the default setting of
| > | > | R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? 
| > Thanks.
| > | >
| > | > Pretty much exactly what I told you in person last week :)
| > | >
| > | > - idea is to prefer /usr/local/lib/R/site-library/
| > | > - multi-user more important than per-user
| > | >
| > | > Also see https://bugs.debian.org/866768
| > | >
| > | > The transition may be too harsh though. I did not consider the
| > possibility of
| > | > /usr/local/lib/R/site-library/ *not* being writeable.  So what I 
| > could do is
| > | > to re-add the per-user directory as a fall-back after the preferred
| > | > /usr/local/lib/R/site-library.
| > | Thanks. The site-library is owned by root/staff on my system, and my
| > | user isn't member of the staff group (Ubuntu 17.04). I'm not sure how
| > | this looks on a factory-fresh install, but IMO users should be able 
| > to
| > | just use install.packages().
| > 
| > You should (as the local admin) set up appropriate groups and policies.
| > 
| > In the simplest case, one addgroup would do.
| 
| While we are in this discussion, I would like to add that admins should 
| be aware of the fact that adding a user to the "staff" group gives a lot 
| of power and responsibility to that user, such a user can add 
| executables to /usr/local/bin which is per default in the PATH of every 

Isn't /usr/local/ having all root:root directories?

| user on the system. These binaries may override those in /usr/bin [1]. 
| This is not necessary for R users that just want to install packages 
| system-wide.
| 
| Shouldn't we recommend a dedicated group for installing R packages in 
| order to avoid these security implications?
| 
| [1] https://wiki.debian.org/SystemGroups

You are free to use staff, or adm, or create one, or ...

Creating one new group by default might be overkill. Locally, however, this
could be a good idea.

Dirk

http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On 2 July 2017 at 23:24, Kirill M?ller wrote:
| On 02.07.2017 22:01, Dirk Eddelbuettel wrote:
| > On 2 July 2017 at 21:39, Kirill M?ller wrote:
| > | Hi
| > |
| > | An upgrade to R 3.4.1 on Ubuntu removed the default setting of
| > | R_LIBS_USER in /etc/R/Renviron. What's the rationale behind this? Thanks.
| >
| > Pretty much exactly what I told you in person last week :)
| >
| > - idea is to prefer /usr/local/lib/R/site-library/
| > - multi-user more important than per-user
| >
| > Also see https://bugs.debian.org/866768
| >
| > The transition may be too harsh though. I did not consider the possibility of
| > /usr/local/lib/R/site-library/ *not* being writeable.  So what I could do is
| > to re-add the per-user directory as a fall-back after the preferred
| > /usr/local/lib/R/site-library.
| Thanks. The site-library is owned by root/staff on my system, and my
| user isn't member of the staff group (Ubuntu 17.04). I'm not sure how
| this looks on a factory-fresh install, but IMO users should be able to
| just use install.packages().

You should (as the local admin) set up appropriate groups and policies.

In the simplest case, one addgroup would do.

Worst case you can also

  i)   wrap sudo around the installation step,
  ii)  make the directory world-writeable or
  iii) set R_LIBS_USER in the *.site files.

I still feel (quite strongly) that this policy is the best, I do also see
that the implementation may not be ideal -- not running install.packages()
well is a bit of a, err, "setback".  Maybe I need to add it again at the end
of .libPath() ?

If I might chime in, I'd like to add my vote to the "users should be able
to use install.packages and should be able to install bioconductor
packages with biocLite".


Longer story
============


Two cases (I've just faced this morning), where
/usr/local/lib/R/site-library/ was not user-writeable:


1. Students using Debian or Ubuntu on their laptops, where these students
are not particularly knowledgeable about Linux.


2. Sys admins that install and configure software for computer labs, where
beyond some bare minima (e.g., R, gcc, etc) users are expected and allowed
to install (some) software on their homes. These sys admins might be
specially reluctant to add users to privileged groups and/or make
/usr/local/lib/R/site-library user-writeable.



The problem is that both groups, after issuing the

sudo apt-get install r-base
sudo apt-get install r-base-dev

(as per https://cran.r-project.org/bin/linux/ubuntu/README.html)


are later surprised when users cannot immediately install packages in the
"usual R way (install.packages)".  And this gets more complicated when we
add a bunch of bioconductor packages, where BioConductor pages often say to
install as


source("https://bioconductor.org/biocLite.R")
biocLite(some_packages)




I've ended up doing

.libPaths(c(the_user_home, .libPaths()))


but this does not look very friendly for new users.





Best,



R.

Dirk

|
|
| -Kirill
|
| > Dirk
| >
|

--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Aut?noma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdiaz02 at gmail.com
       ramon.diaz at iib.uam.es

http://ligarto.org/rdiaz

| If I might chime in, I'd like to add my vote to the "users should be able
| to use install.packages and should be able to install bioconductor
| packages with biocLite".
| 
| Longer story
| ============
| 
| Two cases (I've just faced this morning), where
| /usr/local/lib/R/site-library/ was not user-writeable:
| 
| 1. Students using Debian or Ubuntu on their laptops, where these students
| are not particularly knowledgeable about Linux.
| 
| 2. Sys admins that install and configure software for computer labs, where
| beyond some bare minima (e.g., R, gcc, etc) users are expected and allowed
| to install (some) software on their homes. These sys admins might be
| specially reluctant to add users to privileged groups and/or make
| /usr/local/lib/R/site-library user-writeable.
| 
| The problem is that both groups, after issuing the
| 
| sudo apt-get install r-base
| sudo apt-get install r-base-dev
| 
| (as per https://cran.r-project.org/bin/linux/ubuntu/README.html)
| 
| are later surprised when users cannot immediately install packages in the
| "usual R way (install.packages)".  And this gets more complicated when we
| add a bunch of bioconductor packages, where BioConductor pages often say to
| install as
| 
| source("https://bioconductor.org/biocLite.R")
| biocLite(some_packages)
| 
| I've ended up doing
| 
| .libPaths(c(the_user_home, .libPaths()))
| 
| but this does not look very friendly for new users.

Easier: Remove one # comment character in /etc/R/Renviron which does the same.

As does setting in file /etc/R/Renviron.site (which the package never
touches).

And local policy can (and should!) still be to set a local group.
 
Dirk

http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On 3 July 2017 at 13:05, Ramon Diaz-Uriarte wrote:
| If I might chime in, I'd like to add my vote to the "users should be able
| to use install.packages and should be able to install bioconductor
| packages with biocLite".
|
| Longer story
| ============
|
| Two cases (I've just faced this morning), where
| /usr/local/lib/R/site-library/ was not user-writeable:
|
| 1. Students using Debian or Ubuntu on their laptops, where these students
| are not particularly knowledgeable about Linux.
|
| 2. Sys admins that install and configure software for computer labs, where
| beyond some bare minima (e.g., R, gcc, etc) users are expected and allowed
| to install (some) software on their homes. These sys admins might be
| specially reluctant to add users to privileged groups and/or make
| /usr/local/lib/R/site-library user-writeable.
|
| The problem is that both groups, after issuing the
|
| sudo apt-get install r-base
| sudo apt-get install r-base-dev
|
| (as per https://cran.r-project.org/bin/linux/ubuntu/README.html)
|
| are later surprised when users cannot immediately install packages in the
| "usual R way (install.packages)".  And this gets more complicated when we
| add a bunch of bioconductor packages, where BioConductor pages often say to
| install as
|
| source("https://bioconductor.org/biocLite.R")
| biocLite(some_packages)
|
| I've ended up doing
|
| .libPaths(c(the_user_home, .libPaths()))
|
| but this does not look very friendly for new users.

Easier: Remove one # comment character in /etc/R/Renviron which does the same.

As does setting in file /etc/R/Renviron.site (which the package never
touches).

Thanks for reminding me of that. I am now adding it to my class notes so
I won't forget it again. :-)

I understand that this is for the time being, because if you add the user
directory as a fall-back after the preferred /usr/local/lib/R/site-library,
then modifying /etc/R/Renviron[.site] would not be needed.

And local policy can (and should!) still be to set a local group.

Point taken too.


Best,


R.

Dirk

--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Aut?noma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdiaz02 at gmail.com
       ramon.diaz at iib.uam.es

http://ligarto.org/rdiaz

I wonder if we could take this discussion as an an incentive to start team 
maintenance of the R packaging in a git repository (e.g. on alioth), with a 
higher probability that such a discussion would take place before the upload 
to sid. There are people around that could contribute, like Charles Plessy or 
Don Armstrong, and I think they both could have an interest, and maybe others, 
too.

Cheers,

Johannes