[R-sig-Fedora] Cannot Run On The Command Line

[virgo]

On Thu, 21 Apr 2016 11:17:42 +0100
virgo <cireyapmin at gmail.com> wrote:

> On Thu, 21 Apr 2016 08:23:32 +0000
> Martyn Plummer <plummerm at iarc.fr> wrote:
> 
> > From: Martyn Plummer <plummerm at iarc.fr>
> > To: "cireyapmin at gmail.com" <cireyapmin at gmail.com>,
> > "r-sig-fedora at r-project.org" <r-sig-fedora at r-project.org> Subject:
> > Re: [R-sig-Fedora] Cannot Run On The Command Line Date: Thu, 21 Apr
> > 2016 08:23:32 +0000
> > 
> > Anyway, to address your question I am on FC23 and have no problem
> > with the java JDK available from the Fedora repository (Current
> > version 1.8.0_77). I suggest you use that and not the Oracle one.
> > 
> > Martyn  
> There isn't any issue anymore, the error was related to lack of
> permissions.
> 
> # stat /usr/lib64/R/etc/ldpaths
>   File: ‘/usr/lib64/R/etc/ldpaths’
>   Size: 611       	Blocks: 8          IO Block: 4096   regular
> file Device: fd00h/64768d	Inode: 13762870    Links: 1
> Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/
> root) Context: unconfined_u:object_r:lib_t:s0
> ...
> 
> # chmod go+r /usr/lib64/R/etc/ldpaths
> 
> $ R --quiet
> >  
> 
> I don't know how and why the root's group and others lost read access
> to that ldpaths file after R CMD javareconf-iguring, 
As one could expect even without reading the sources of 'R CMD
javareconf', the script is modifying the permissions.

$ R --version
R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree"
Copyright (C) 2015 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu (64-bit)

# stat /usr/lib64/R/etc/ldpaths
...
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
...

# inotifywait --monitor --timefmt '%s' --format '%w %T %e' \
--outfile what-s_happening /usr/lib64/R/etc/ldpaths & 

# R CMD javareconf

# stat /usr/lib64/R/etc/ldpaths
...
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
...

# cat what-s_happening 
/usr/lib64/R/etc/ldpaths 1461430370 OPEN
/usr/lib64/R/etc/ldpaths 1461430370 ACCESS
/usr/lib64/R/etc/ldpaths 1461430370 CLOSE_NOWRITE,CLOSE
/usr/lib64/R/etc/ldpaths 1461430370 OPEN
/usr/lib64/R/etc/ldpaths 1461430370 ACCESS
/usr/lib64/R/etc/ldpaths 1461430370 CLOSE_NOWRITE,CLOSE
/usr/lib64/R/etc/ldpaths 1461430372 OPEN
/usr/lib64/R/etc/ldpaths 1461430372 ACCESS
/usr/lib64/R/etc/ldpaths 1461430372 CLOSE_NOWRITE,CLOSE
/usr/lib64/R/etc/ldpaths 1461430372 OPEN
/usr/lib64/R/etc/ldpaths 1461430372 ACCESS
/usr/lib64/R/etc/ldpaths 1461430372 CLOSE_NOWRITE,CLOSE
/usr/lib64/R/etc/ldpaths 1461430372 OPEN
/usr/lib64/R/etc/ldpaths 1461430372 ACCESS
/usr/lib64/R/etc/ldpaths 1461430372 CLOSE_NOWRITE,CLOSE
/usr/lib64/R/etc/ldpaths 1461430372 OPEN
/usr/lib64/R/etc/ldpaths 1461430372 ACCESS
/usr/lib64/R/etc/ldpaths 1461430372 CLOSE_NOWRITE,CLOSE
/usr/lib64/R/etc/ldpaths 1461430372 ATTRIB
/usr/lib64/R/etc/ldpaths 1461430372 DELETE_SELF

‘man inotifywait’ describes the ‘ATTRIB’ and ‘DELETE_SELF’ events above
this way:
“attrib    The  metadata  of  a  watched  file  or a file within a
watched directory was modified.  This includes timestamps, file
permissions, extended attributes etc.”

“delete_self    A watched file or directory was deleted. After this
event the file or directory is no longer being watched.  Note that
this  event can occur even if it is not explicitly being listened for.”

So, I looked at what R-3.2.3/src/scripts/javareconf.in is doing and
the code shows it's interfering with the umask. Indeed, between the
lines #400 and #413, a loop is first sed-ing, and shortly after mv-ing
on files including the above /usr/lib64/R/etc/ldpaths. The local umask
is 0077, so that mv operation can't fail to change the access attributes
of the targeted files, from readability for anyone to root-only
readable. Some questions arise from that :

- What if the sed looked like sed --in-place? That would not silently
  change the users' umask as far as I can tell.

- If sed-ing in-place isn't an option, wouldn't be worth of it to
  consider other ways achieving similar goals than those of L400-L413
  without meddling with access attributes?

- If this is an issue that should be solved, is this place the right
  place to talk/write about it?

> but at least the
> R session is back and that is enough for me.
> 
> Sorry for the noise, if any.