From edd at debian.org  Sat Jun 15 05:27:32 2013
From: edd at debian.org (Dirk Eddelbuettel)
Date: Fri, 14 Jun 2013 22:27:32 -0500
Subject: [Rd] R CMD INSTALL and file permission settings
In-Reply-To: <046C1EB4-F22D-457F-BB2C-27D666E3418F@r-project.org>
References: <20915.23136.75704.347469@max.nulle.part>
	<20917.40985.705751.95999@stat.math.ethz.ch>
	<20923.30546.509634.752403@stat.math.ethz.ch>
	<1A628E3D-CC34-4C38-B23B-03169D3C7AD0@r-project.org>
	<20923.32408.400045.470669@max.nulle.part>
	<046C1EB4-F22D-457F-BB2C-27D666E3418F@r-project.org>
Message-ID: <20923.57124.150011.263475@max.nulle.part>


On 14 June 2013 at 16:56, Simon Urbanek wrote:
| On Jun 14, 2013, at 4:35 PM, Dirk Eddelbuettel wrote:
| > But up until right now I could not update a package a colleague installed,
| > and vice versa -- unless we sudo.  
| > 
| 
| But you should be able to simply removing it, and re-installing, right? (This is not to suggest it as a work-around, but rather to make sure we're taking about the same situation). 

I think not:  

  -- 'Alice' and 'Bob' are both members of 'r-users'. 

  -- Alice installs, it becomes '644' / '755' owned by 'alice:r-users'.  

  -- Bob tries to update (or remove, as you suggest)

  -- Bob has no group-write (despite sharing the group) or world-write rights

  -- Hence this fails

  -- My patch (reworked by Martin) fixes precisely this

| The implementation of the group-wrtable part of is great improvement, but my point is that this doesn't solve the update.packages() problem that triggered the fix, because the flag is ignored then:
| 
| $ bin/R CMD INSTALL --group-writable ~/develop/R/packages/base64enc_0.1-0.tar.gz 
| $ ls -ld library/base64enc
| drwxrwxr-x  10 urbanek  admin  340 Jun 14 16:48 library/base64enc

Mode 775, good.

| $ sudo -u user2 bin/R -e 'update.packages(ask=F)'
| $ ls -ld library/base64enc
| drwxr-xr-x  11 user2  admin  374 Jun 14 16:49 library/base64enc

Mode 755 -- why?

| $ bin/R -e 'update.packages(ask=F)'
| [...]
| mv: rename /Volumes/Data/Builds/R-builds/rd/library/base64enc to /Volumes/Data/Builds/R-builds/rd/library/00LOCK-base64enc/base64enc: Permission denied
| Warning in file.copy(f, instdir, TRUE) :
|   problem copying ./NAMESPACE to /Volumes/Data/Builds/R-builds/rd/library/base64enc/NAMESPACE: Permission denied
| Warning in file.copy(f, instdir, TRUE) :
|   problem copying ./NEWS to /Volumes/Data/Builds/R-builds/rd/library/base64enc/NEWS: Permission denied
| Warning in file(file, ifelse(append, "a", "w")) :
|   cannot open file '/Volumes/Data/Builds/R-builds/rd/library/base64enc/DESCRIPTION': Permission denied
| Error in file(file, ifelse(append, "a", "w")) : 
|   cannot open the connection
| ERROR: installing package DESCRIPTION failed for package ?base64enc?

I will admit to having written and tested the patch at home, under single
user, not work.  But at work I "simulated" the exact same situation by doing
repeated 'sudo chmod -R g+w /usr/local/lib/R/site-library' after which 'Bob'
can indeed updated packages installed by 'Alice'.

Which is the whole point.
 
| So, as I was suggesting to use the patch to implement a more durable solution which doesn't need an extra flag but just checks the permissions on the library. While at it, it could also consult umask and thus be a good citizen ...

We can always refine, but I still think that we're better off with the patch
than before.

Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com



[Rd] R CMD INSTALL and file permission settings
Dirk Eddelbuettel