Let's presuppose that you have R running with root/admin privileges. What R calls do you consider harmful, apart from system() and file.*()?
This is a platform-specific question, I'm running Linux, so I'm interested in Linux-specific security leaks. I will understand if you block discussions about R, since this post can easily emerge into "How to mess the system up with R?"
Anything that calls external code could also be making system changes, so you would need to block certain packages and things like .Call(), .C(), .jcall(), etc.
Suffice it to say that it will end up being a virtually impossible task, and you are better off running it in a virtualized environment, etc. if you need root access.
You can't. You should just change the question: "How do I run user-supplied R code so as not to harm the user or other users of the system?" That's actually a very interesting question and one that can be solved with a little bit of cloud computing, apparmor, chroot magic, etc.
Do not run R with root privs. There is no effective way to secure R in this way, since the language includes eval and reflection, which means I can construct invocations to system even if you don't want me to.
Far better is to run R in a way that cannot affect the system or user data, no matter what it tries to do.
There are tons of commands you could use to harm the system. A handful of examples: Sys.chmod, Sys.umask, unlink, any command that allows you to read/write to a connection (there are many), .Internal, .External, etc.
And if you blocked users from those commands, there's nothing stopping them from implementing something in a package that you wouldn't know to block.
To adapt a cliche from gun rights people, "system() isn't harmful - people who call system() are harmful".
No function calls are intrinsically harmful, but if you allow people to use them freely then those people may cause harm.
Also, the definition of harm will depend on what you consider harmful.
As noted by just about every response to this thread, removing the "potentially harmful" calls in the R language would:
A safer solution that doesn't require modifying/rewriting large parts of the R language would be to run R inside a jail using something like BSD Jails, Jailkit or Solaris Zones.
Many of these solutions allow the jailed process to exercise root-like privileges but restrict the areas of the computer that the process can operate on.
A disposable virtual machine is another option. If a privileged user thrashes the virtual environment, just delete it and boot another copy.
In general, R is so complex that you can assume that there is a way to trick it in executing data with seemingly harmless functions, for instance through buffer overflow.