Skip to content

The new GUI: help font; root

5 messages · Jussi Piitulainen, Thomas Lumley, Simon Urbanek +1 more

#
My first impression of the Cocoa GUI in 2.0.1 is very positive. Great
work. Thank you.

My favourite improvement so far is the help browser. Among other nice
things, I was happy to see that arrow keys now scroll the text. But
Command-+ does not make the font bigger yet. It only flashes a menu.
Please, make this work. (Not as urgent as resizing the Quartz device.)

In the console window, fonts resize nicely. Thank you.

There is a prominent button for letting R use root privileges. This is
really scary. Please, could the code in question be removed? Not just
hidden but removed. Don't risk the stability of my computer for some
convenience. (What is it for? To mess with the kernel?)

(The "quit" button is merely redundant.)
#
On Fri, 19 Nov 2004, Jussi Piitulainen wrote:
I assume it is to allow you to install packages system wide. You can just 
not use it -- it's not a bomb that can go off accidentally. Remember that 
R can't possibly increase its own privileges, so the button uses the same 
OS interface that installers use, to get the OS to ask you for your 
permission and password. Any code on the Mac can *ask* for this, the 
security comes from the fact that the OS puts up a standard, recognizable 
prompt and the user has to explicitly give permission.  People who give 
permission without thinking will quickly destroy their computers whatever 
R does.

I wouldn't have put this in myself -- I would rely on sudo R CMD INSTALL 
or on setting up appropriate group permissions if I wanted to install 
packages system-wide.  However, if you want a GUI package installer it has 
to be able to request permission to write to protected directories, and 
the button has to be slightly safer than starting up the R GUI with admin 
privileges, if only because the privileges are invoked for a shorter time.

 	-thomas
1 day later
#
On Nov 19, 2004, at 1:14 PM, Jussi Piitulainen wrote:

            
Thomas nicely explained the reason behind the button and where your 
seem to misunderstand the way such things work and the implications.

Just for completeness, technically what happens is that the R_system 
call is authorized to run as root if authenticated as long as the lock 
is unlocked (pretty much like in all Apple applications BTW). It does 
not change the privileges of R.app itself. The main reason for this 
functionality is that there is no way to run R.app as root for 
system-wide tasks and "sudo R" does not give you necessarily the same 
environment (let alone GUI for package installation ;)).

Cheers,
Simon
#
Just as an experiment I tried the following.  First, as the root user I 
created a file named unlink.me in /:

[muffin] /> ls -l
total 8753
<snip>
-rw-r--r--   1 root  admin       11 21 Nov 13:15 unlink.me
<snip>

Then I started up R, clicked on the lock and authenticated myself.  I 
was able the delete unlink.me with the command

 > unlink("/unlink.me")

The unlink function is defined as

 > unlink
function (x, recursive = FALSE)
{
     if (!is.character(x))
         stop("argument must be character")
     if (recursive)
         system(paste("rm -rf ", paste(x, collapse = " ")))
     else system(paste("rm -f ", paste(x, collapse = " ")))
}
<environment: namespace:base>

So when the lock is unlocked one really is only a typo away from some 
potentially serious harm (remember the iTunes installer?).  I think a 
good short term solution would be to have R ask for a password for each 
operation requiring root privileges and deauthenticate when that 
operation is complete.  It would also be good if the dialog could tell 
you what the operation is.  For instance, "R needs your password to 
install the the package ${packageName}."

Just my 2 cents.

Kjell
On 21 Nov 2004, at 12:54, Simon Urbanek wrote:

            
#
On Nov 21, 2004, at 2:39 PM, Kjell Konis wrote:

            
Well, but this is true for ANY shell ran as root - with sudo R you're 
exactly in the same position, even worse as you can create files by 
writing as root (which you can't in R.app), so I don't quite get your 
point. When you authorize yourself as root, you should know what you're 
doing. As Thomas said - giving authorization without thinking will give 
any application the rights to kill your system.
Unfortunately both things are not possible. SF provides no way to 
specify a message the user should get. Secondly there is no guarantee 
that the performed operation is atomic - if you patch R_system you will 
see that it's called more than once for seemingly single operations, so 
it's not clear when to deauthenticate. We did indeed discuss the whole 
issue before implementing it :P.

So the bottom line is that the tool is pretty harmless and safe for 
regular users, as the user has to acknowledge their responsibility by 
authenticating. It could be argued whether the icon should be present 
in the bar by default (e.g. I'd propose to make it visible by default 
to admin users only), but so far I see no argument against the feature 
in general.

Cheers,
Simon