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 | e...@debian.org _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian