My question is asking regarding a specific observation that I would like to understand.

I just tried to install the package rJava in R and failed even though I prefaced the installation as suggested by the manual with:

sudo R CMD javareconf

Then I came across this comment:

Using sudo and running as root are not exactly the same thing. – Jon7

Desparate as I was I tried it:

sudo su
R CMD javareconf

And to my surprise I suddenly could install that package.

Sorry for the lenghty introduction but I wanted to give you a context to prevent answers like here. The question does not aim at specifically the described observation - rather at those "things" in general on Ubuntu.

My question is: How could this be possible? What is the difference between sudo X and runnding X as root?


That's somewhat too broad to explain it will end with conclusion like in a link that you linked to your question, but I'll try something more fullfilled maybe it will give you some answers.

sudo ("substitute user do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments.

Sudo is an alternative to su for running commands as root. Unlike su, which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege escalation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelihood that a typo or a bug in an invoked command will ruin the system. Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts for security auditing.

More detailed info about Root Sudo can be found on Official Ubuntu Documentation

  • thanks! how does this relate to the situation I describe? is sudo not able to execute everything in the wake of X?
    – Raffael
    Jun 8 '14 at 9:28
  • as mentioned in my answer root allows all further commands root access, sudo instead grants temporary privilege escalation the command you're trying to execute requires more privileges than sudo(admin) it requires root(owner), to explain you this way, because you might be doing the change to the system standard.
    – JoKeR
    Jun 8 '14 at 9:32

This tutorial is taken from the original homepage:

IMG:   Sudo in a Nutshell

Sudo (su "do") allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell. Its features include:

  • The ability to restrict what commands a user may run on a per-host basis.
  • Sudo does copious logging of each command, providing a clear audit trail of who did what. When used in tandem with syslogd, the system log daemon, sudo can log all commands to a central host (as well as on the local host). At CU, all admins use sudo in lieu of a root shell to take advantage of this logging.
  • Sudo uses timestamp files to implement a "ticketing" system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes (this timeout is configurable at compile-time). Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.
  • Sudo's configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user's privileges on a per-host basis. Please see the samples sudoers file below for a real-world example.


UNIX root account is all or nothing.

In computing, the superuser is a special user account used for system administration. Depending on the operating system (OS), the actual name of this account might be root, administrator, admin or supervisor. In some cases, the actual name of the account is not the determining factor; on Unix-like systems, for example, the user with a user identifier (UID) of zero is the superuser, regardless of the name of that account and in systems which implement a role based security model, any user with the role of superuser (or its synonyms) can carry out all actions of the superuser account. The principle of least privilege recommends that most users and applications run under an ordinary account to perform their work, as a superuser account is capable of making unrestricted, potentially adverse, system-wide changes.(a)

(a) from https://en.wikipedia.org/wiki/Superuser

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.