typically rather independently, in the background of the operating system. root is the conventional name for the master administrative user or superuser, with privileges to do anything and everything. And nobody is the conventional name for the user under which the Apache Webserver application httpd is run.
This nobody user we call unprivileged, but that means nothing more than that it can’t log in. Since the nobody user exists only to run the public Webserver, its access to the system can and should be extremely limited.
In truth, however, nobody becomes by its activities probably the most privileged user on any mass virtual hosting system (aside from root); its business turns into everybody’s business, nobody sees nearly every file, nobody executes the vast majority of scripts, nobody talks to all the databases, and nobody is invited to write to locations all over the /tmp and /home partitions.
Even though different applications on a shared host may use different usernames and passwords to connect to different databases, nobody’s wide-ranging access can be used to discover the information necessary to connect to any of them. Consider the following script, which is intended to read other users’ config.php files:
<?php
header( 'Content-Type: text/plain' );
$otherUsers = array( 'user1', 'user2', 'user3' );
foreach( $otherUsers AS $username ) {
print "$username's config:\n";
print file_get_contents( "/home/$username/config.php" );
}
?>
On a shared host, a script such as this can be used to print the contents of any other PHP script on the server. In this case, it would print the contents of each of the listed users’ config.php scripts, which could very well contain database passwords or other confidential information.
PHP has a Safe Mode option that should prevent this specific attack, but there is nothing illegal about the script from the operating system’s point of view. The web applications in each of these users’ home directories are executable by nobody, so we know nobody is capable of accessing that config.php file.
Of course, it doesn’t matter under what name the Webserver runs; it could be user www or user 'user1'. The point is that that user has the capability to run a script. If you can make it do that, you can most likely trick it into revealing any other Webserver-readable file on the system. The difficulty of doing so is an excellent measurement of a hosting provider’s security consciousness.