[Rd] R CMD INSTALL and file permission settings

[Martin Maechler]

>>>>> Dirk Eddelbuettel <edd at debian.org>
>>>>>     on Fri, 14 Jun 2013 22:27:32 -0500 writes:

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

because update.packages calling install.packages() does not
preserve the group-writability.

I think this was the most important point by Simon, and I agree
that we should further improve the current R-devel (it *is*
in ongoing development, so all is fine).


    > | $ 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.

well, modulo the update.packages() example above ,..

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

I think we could agree that we basically all agree, at least
with these two

1) The current R-devel code, basically Dirk's patches, is an
   improvement to the previous situation.

2) It needs to be further tweaked and improved in order to
   "coexist" nicely with  update.packages(), install.packages().

The question really is, and I understand that's Simon's Q,
if there is a solution to this problem which makes the use of
'--group-writable' almost (or completely?) superfluous.

IIUC, Simon proposes that  the *library* directory (aka
'lib.loc')'s group permissions should be determinant for the
package's group permissions in all(?) cases.
notably when the library is group writable, packages should all
be installed (and hence also updated) group writably in any case.
I tend to agree with Simon on this proposal.

The other issue is "respecting" the umask.
Here, I'm much less sure what we want.
Many organizations have quite rigid umask defaults, also in my
experience, about 2-5% of the users are relatively paranoid and
learn to set their own umasks quite restrictively.
So, if these are "part of our group", and if they update a
package in our group-writable library, should their paranoid
umask setting really be taken for the newly installed package?
My vote would be "no"...
and I more and more tend to think that a simple scheme such as
(I think Simon proposed) to simply install packages
"all group writable" in a group-writable directory would be
entirely sufficient.

Comments?

Martin