[R-sig-Debian] /etc/R/Renviron doesn't set R_LIBS_USER anymore

[Dirk Eddelbuettel]

On 3 July 2017 at 10:16, Ranke, Johannes wrote:
| On 2017-07-03 09:58, Dirk Eddelbuettel wrote:
| > 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 

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