[R-SIG-Mac] CRAN installer for macOS - directory permissions

Wed Apr 13 10:43:01 CEST 2022

@Simon

A response to my last reply would be appreciated.
It also seems that I am not the only one sharing this view and even more people might be interested in your knowledge and thoughts about this topic :)

Related to this Q: Are the macOS CRAN policies actively discussed by a team of people (who might eventually also be willing to share their thoughts or could be addressed with such questions) or are you solely responsible for it?

Best,
Patrick

On 3 Apr 2022, at 10:26, Patrick Schratz wrote:

> Hi Simon,
>
> thanks for your extensive reply.
>
>> The choice is deliberate: the admin group on macOS corresponds to users that are allowed to install system-wide software so it allows all admins on the machine to install packages which is the expected way on macOS.
>
> I think this choice is unfortunate as it contrasts with existing behavior on other platforms where one needs to explicitly request admin privileges by either using `sudo` or starting R as an admin.
> On macOS, packages just go into the system lib “silently” because of the write permissions granted via the `admin` group.
> See also my comments further down for more details on this.
>
>> Also the versioning of the R framework as x.y is also deliberate - upgrading R to a new patch version does *not* require re-installation of packages, they work by design so in fact the system location is the safest way to do that. Also note that packages are never removed by the installer.
>
> Thanks, I am aware that a patch update does not require a reinstallation as the packages are functional across minor versions.
>
> I checked again and was indeed wrong, patch updates from the CRAN installer do not remove additional custom packages in the system lib.
> I was confused by some custom approaches of mine which cause this behavior - sorry for this!
>
>> So out of the items listed in "The problem" they are all not true with the exception of the comparison with the other platforms, but even that difference is very subtle as it only affects the default on the first installation and not regular use (and I'm, not even sure it that is true since admin users can still install in the system location on other platforms).
>
> On Linux you would need to do explicitly invoke `sudo R` to allow writing into the system lib.
> The issue on macOS is that a regular start of `R` allows system lib write permissions.
> In my current view I think a similar behavior as on Linux would be great, i.e. to explicitly having to request admin privileges for this task.
>
> I don’t understand the part “as it only affects the default on the first installation and not regular use” of your reply - could you clarify this?
> Unless a user creates a user lib manually, packages will always go into the system lib - not only on first use - but I might be misunderstanding your comment here.
>
>> I would argue that the current setup tends to be a lot safer than the alternatives, because it allows commonly used packages to be installed at the system level and private packages to be installed at user level. This is also the design typically used on shared machines, where you separate local packages from user packages where local ones are installed by administrators - so exactly the same setup. Moreover R upgrades are a lot cleaner, since you can easily upgrade all system packages at once so you don't have to worry about individual users having stale packages - the biggest problem for admins.
>
> Yes and no.
> Sometimes system admins want to install certain packages globally - however, I never do so for the following reason:
> Often this will lead to multiple package installations, i.e. one in the syslib and one in the user lib (if the user installs the package again for some reason which quite often happens).
> Often these duplicated packages will have different versions and users are confused which one is actually loaded (the user lib one is as it is first in the path).
>
> Aside from this practical point, Macs are rarely used in a shared way.
> And even if, I’d highly favor having to request write permissions into the syslib rather it happening by default.
>
> Imagine a scenario where the admin of a shared Mac constantly writes into the syslib (because this is the default). This syslib is then also used by other non-admin users on the system.
> I don’t think this is a desired scenario and might cause lot’s of confusion (not even mentioning the fact if all people in this scenario are aware what’s going on given that this is a niche topic).
> Here I think a one-time central installation of R and then only working with user libs (as on Linux) would be preferable.
>
> From a technical perspective, I know that setting `root:root` on macOS is not possible. My proposed change to `755` (and leaving `root:admin`) would however exactly mimic this (**and the one of Linux installs**) behavior:
>
> - admins would need to do `sudo R` to install into the system library
> - otherwise they are prompted to create a user library
>
> Which downsides would this approach have? Currently I don’t see any. It would even harmonize CRAN installer behavior across platforms.
>
>> I'd be happy to hear from more Mac user if there are reasons to change the default, but as I outlined the choices were deliberate after weighting the pros and cons. In my view the major issue with the proposal it that is would prevent sharing of packages, make R upgrades a lot harder and prevent admin users from using the current tools for package management - and that includes the ability to separate system and user packages on single-user machines.
>
> I’ll try to vision the practical changes of this:
>
> - Patch update experience would not change as custom packages will be in the user lib for the respective minor version (by default)
> - Admins are **still** able to install into the system lib when using `sudo R`
> - AFAICS admins will still be able to separate system and user packages as they can use `sudo R` for syslib installs. To me, the proposed change would even make the behaviour more clear than before (which requires to create a hidden folder (user lib) in the right place to actually use a user lib).
>
> Let me know if I overlook something - but currently I don’t see any downside but various positive impacts.
>
>> Last, I wanted to ask if the source code for the CRAN installer is publicly available? I could not find it and would be interested to take a look into it. If this is not possible for some reason, I would also be interested in getting to know the reason for this decision.
>
> I’d also still appreciate a reply to this - maybe it got overlooked.
>
>
> Cheers
> Patrick
>
> On 1 Apr 2022, at 23:43, Simon Urbanek wrote:
>
>> Patrick,
>>
>> thanks for starting the discussion.
>>
>> The choice is deliberate: the admin group on macOS corresponds to users that are allowed to install system-wide software so it allows all admins on the machine to install packages which is the expected way on macOS.
>>
>> Also the versioning of the R framework as x.y is also deliberate - upgrading R to a new patch version does *not* require re-installation of packages, they work by design so in fact the system location is the safest way to do that. Also note that packages are never removed by the installer.
>>
>> Packages are not compatible beyond the patch version so the current setup avoids the most common problem where users inadvertently use packages installed for an incompatible previous R version leading to crashes. To make R upgrades easy the R GUI Package Installer offers specifically the option to install packages from the previous R version. This allows for a clean and safe upgrade of R.
>>
>> So out of the items listed in "The problem" they are all not true with the exception of the comparison with the other platforms, but even that difference is very subtle as it only affects the default on the first installation and not regular use (and I'm, not even sure it that is true since admin users can still install in the system location on other platforms). The user has full control over where they install a package - it's a simple click to change the default to whatever you prefer. Also I'd like to point out that once you start using the user library, it becomes the default for install.packages() so typically installing packages into system location requires deliberate choice over the user library(*). Note that the behavior of the user library is common across platforms, so I'm not really sure the is any real difference.
>>
>> I would argue that the current setup tends to be a lot safer than the alternatives, because it allows commonly used packages to be installed at the system level and private packages to be installed at user level. This is also the design typically used on shared machines, where you separate local packages from user packages where local ones are installed by administrators - so exactly the same setup. Moreover R upgrades are a lot cleaner, since you can easily upgrade all system packages at once so you don't have to worry about individual users having stale packages - the biggest problem for admins.
>>
>> I'd be happy to hear from more Mac user if there are reasons to change the default, but as I outlined the choices were deliberate after weighting the pros and cons. In my view the major issue with the proposal it that is would prevent sharing of packages, make R upgrades a lot harder and prevent admin users from using the current tools for package management - and that includes the ability to separate system and user packages on single-user machines.
>>
>> Cheers,
>> Simon
>>
>>
>> (*) while looking into this I noticed there is a bug in the latest R GUI where Renviron and the GUI don't agree on the location of the user library (due to the addition of the architecture to the path) so I agree that the the GUI should be fixed to
>> match the location.
>>
>>
>>
>>
>>> On Apr 2, 2022, at 2:08 AM, Patrick Schratz <patrick.schratz using gmail.com> wrote:
>>>
>>> Dear fellow R users on macOS,
>>>
>>> I'd like to discuss the current directory permissions set by the CRAN
>>> installer for macOS (https://cran.r-project.org/).
>>> The installers installs R into `/Library/Frameworks/R.framework/` with
>>> 775 permissions.
>>> In contrast to 755, 775 also gives the defined group write permissions.
>>> The group for `/Library/Frameworks/R.framework/` is `admin`.
>>> Many users use a Mac in a single-user setup, i.e. only one user is using
>>> the machine.
>>> This is usually also an administrator, i.e. the user is a member of the
>>> `admin` group.
>>>
>>> ## The problem
>>>
>>> Being a member of `admin` group gives subsequently write access into the
>>> R system library, i.e. the library which stores the package which are
>>> bundled with the installer (base, MASS, parallel, etc.).
>>> This is problematic for several reasons:
>>> - user packages are mixed with system packages
>>> - if a new R version is installed, all packages in the system library
>>> are lost as they are getting overwritten by the CRAN installer
>>> - on other platforms (Windows, Linux) the system library is not writable
>>> by default, hence the behaviour of the macOS CRAN installer is different
>>> from the other platforms
>>>
>>> Besides the differing experience for users on macOS compared to other
>>> platforms (which constantly causes confusion for R users switching
>>> platforms), the above also causes many unneeded R package downloads,
>>> e.g. users are forced to reinstall all packages for every patch version
>>> update of R.
>>>
>>> In case you are wondering why R does not offer to create a user library
>>> as on other platforms: if the system library is writable (or R detects
>>> any writable library configured in the repos option), the prompt will
>>> not appear.
>>> If a user manually creates a user library at the expected path (e.g
>>> .`$HOME/Library/R/arm64/4.1/library`), R will pick it up and packages
>>> will go into the user library.
>>> However, most R users don't want to bother with this and are no experts
>>> in their local library management.
>>>
>>> ## How can the following possibly be solved?
>>>
>>> AFAICS the easiest way would be to set 755 instead of 775 permissions
>>> for the `/Library/Frameworks/R.framework/` folder.
>>> I don't see a reason why write permissions for the `admin` group would
>>> be needed.
>>>
>>> I've tested this in a few scenarios and did not face any issues.
>>> Also I've come across an interesting observation while doing so:
>>> While R in the terminal offers the creation of the user lib if
>>> permissions are 755
>>>
>>> ```
>>> [ins] r$> .libPaths()
>>> [1]
>>> "/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library"
>>>
>>> [ins] r$> install.packages("<package>")
>>> Warning in install.packages("<package>") :
>>>   'lib =
>>> "/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/library"'
>>> is not writable
>>>
>>> [ins] Would you like to use a personal library instead? (yes/No/cancel)
>>> yes
>>> [ins] Would you like to create a personal library
>>> ```
>>>
>>> RStudio does it even silently in the background (which is quite nice
>>> imo).
>>> To reproduce:
>>> 1. Install R for Mac via the CRAN installer
>>> 2. `sudo chmod -R 755 /Library/Frameworks/R.framework/`
>>> 3. `R -q -e ".libPaths()"` (should only return the system library)
>>> 4. Open RStudio
>>> 5. `R -q -e ".libPaths()"` (should return two libraries, with the user
>>> lib being the first)
>>>
>>> If for some reasons 755 cannot be set for the `R.frameworks`
>>> directories, then the group defined for `R.frameworks` (and recursive
>>> directories) could possibly be changed to prevent direct writes access
>>> to the R system lib.
>>>
>>> Last, I wanted to ask if the source code for the CRAN installer is
>>> publicly available? I could not find it and would be interested to take
>>> a look into it.
>>> If this is not possible for some reason, I would also be interested in
>>> getting to know the reason for this decision.
>>>
>>> Best regards,
>>> Patrick
>>> 	[[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac using r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20220413/5a9c260a/attachment-0001.html>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: OpenPGP digital signature
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20220413/5a9c260a/attachment-0001.sig>