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

[Patrick Schratz]

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]]