Virtualizing super-user privileges for multiple virtual processes

Abstract

Super-user privileges are virtualized by designating a virtual super-user for each of a plurality of virtual processes and intercepting system calls for which actual super-user privileges are required, which are nevertheless desirable for a virtual super-user to perform in the context of his or her own virtual process. In one embodiment, a computer operating system includes multiple virtual processes, such as virtual private servers. Each virtual process can be associated with one or more virtual super-users. When an actual process makes a system call that requires actual super-user privileges, the call is intercepted by a system call wrapper.

Description

where UID is the UID 305, VPID is the VPID 203 (from the table 127), and “<<” and “|” are the left shift and logical “OR” operators, respectively. In other words, the VPID 203 is left shifted 16 bits and then logically ORed with the UID 305.

Those skilled in the art will recognize that the above-described technique limits the number of unique UIDs 305 and virtual processes 101 to 65536, respectively. In alternative embodiments, however, the relative location and/or number of bits allocated to the VPID 203 within the UID 305 may vary, resulting in different limitations.

After the UID 305 is modified, the system call wrapper 111 associates the resource with the modified UID 305. This may be accomplished, in one embodiment, by executing the system call 115 by the wrapper 111, specifying the modified UID 305. In an alternative embodiment, the system call wrapper 111 can include its own code for setting the UID 305.

Consequently, from a standpoint of the calling process 301, the resource is associated with the UID 305 specified in the system call 115. From a standpoint of the operating system 117, however, the resource is actually associated with the modified UID 305.

FIG. 4 provides an example of the above-described technique. Suppose that a process 301 having a PID 201 of 3942 attempts to execute the UNIX® setuid( ) system call 115 with a specified UID 305 of 1. As shown, the system call wrapper 111 uses the virtual process table 127 to determine the VPID 203 (e.g., 1) associated with the calling process 301. The VPID 203 is then encoded within UID 305 as described above, resulting in a modified UID 305 having a hexadecimal value of 0x00010001 (65537 in decimal). Accordingly, the calling process 301 is associated with a UID 305 of 65537 rather than the specified UID 305 of 1.

As shown in FIG. 5, a different UID 305 will result from a different VPID 203. For instance, suppose that the VPID 203 of the virtual process 101 of FIG. 5 has a value of 3. Applying the above-described equation, the resulting modified UID 305 has a hexadecimal value of 0x00030001 (196609 in decimal). Accordingly, the calling process 301 is associated with a UID 305 of 196609 rather than the original UID 305 of 1 or the modified UID 305 of 65537 from the previous example.

The above-described technique for virtualizing resource ownership is summarized in FIG. 6. A method 600 begins in one embodiment by loading 601 a system call wrapper 111 into the operating system 117. Thereafter, copies are made 603 of pointers 114 to selected system calls 115 to be intercepted (e.g., setuid( ), setgid( ), and chown( )). The pointers 114 are then replaced 605, in one implementation, by pointers 118 to the system call wrapper 111. Thus, when one of the selected system calls 115 is made, the system call wrapper 111 is executed instead.

A system call 115 for setting the UID 305 of a resource is then intercepted 607. Next, the system call wrapper 111 determines 609 the virtual process 101 corresponding to the calling process 301. In one embodiment, this determination is made by referencing the virtual process table 127, as described above.

After the virtual process 101 is determined, the system call wrapper 111 encodes 611 an indication of the virtual process 101 (e.g., the VPID 203) within the UID 305. The wrapper 111 then associates 613 the resource with the modified UID 305. In one implementation, this is accomplished by executing the system call 115 within the wrapper 111, specifying the modified UID 305.

Another aspect of virtualizing resource ownership involves intercepting system calls 115 for obtaining the UID 305 or GID 307 associated with a system resource. In the case of UNIX®, the getuid( ) function returns the UID 305 associated with the calling process 301. Similarly, the UNIX® getgid( ) function returns the GID 307. Additionally, the UNIX® stat( ) function returns the UID 305 and/or GID 307 associated with a file 303. Of course, the invention is not limited to any particular terminology or operating system 117.

Consequently, if a system call 115 for obtaining a UID 305 (e.g., getuid( )) were allowed to execute without modification, the calling process 301 would receive a “modified” UID 305, such as a UID 305 including an indication of a virtual process 101. From the standpoint of the calling process 301, the UID 305 would be unexpected, with unpredictable results.

Thus, FIG. 7 illustrates a system 700 for virtualizing resource ownership. After intercepting one of the above-identified system calls 115, the system call wrapper 111 obtains the UID 305 from the standpoint of the operating system 117. The wrapper 111 obtains the UID 305, in one embodiment, by executing the system call 115. In alternative embodiments, the wrapper 111 may include its own code for obtaining the UID 305.

In one embodiment, the UID 305 obtained by the wrapper 111 includes an indication of the virtual process 101 (e.g., VPID 203). Thus, the wrapper 111 removes the VPID 203 to restore the original, unmodified UID 305, as described in greater detail below.

As previously explained, a UID 305 in Solaris® is a 32 bit word. In one implementation, the upper 16 bits are used to encode the VPID 203, while the lower 16 bits are used to store the UID data. Thus, the VPID 203 may be removed from the UID 305 by applying the equation:
UID=0x0000FFFF & UID  Eq. 2
where UID is the UID 305 and “&” is the logical “AND” operator. In other words, the set of bits corresponding to the VPID 203 within the UID 305 are cleared. Of course, the encoding of the VPID 203 may vary in alternative embodiments, necessitating a different equation.

An example of the above-described process is shown in FIG. 7. Suppose that a process 301 executes the UNIX® getuid( ) system call 115, which is intercepted by the system call wrapper 111. The wrapper 111 obtains the UID 305 (e.g., 0x00010001) associated with the resource by executing, for example, the system call 115. As illustrated, the upper 16 bits of the UID 305 include an indication of a virtual process 101 (e.g., a VPID 203 of 1).

The wrapper 111 then removes the indication of the virtual process 101 by logically ANDing the UID 305 with a value configured to clear the bits associated with the VPID 203, (e.g., 65535). As a result, a UID 305 of 1 is returned to the calling process 301, rather than the UID 305 of 65537.

The above-described technique for virtualizing resource ownership is summarized in FIG. 8. A method 800 begins in one embodiment by loading 801 a system call wrapper 111 into the operating system 117. Thereafter, copies are made 803 of pointers 114 to selected system calls 115 to be intercepted (e.g., getuid( ), getgid( ), and stat ( )). The pointers 114 are then replaced 805, in one implementation, by pointers 118 to the system call wrapper 111. Thus, when one of the selected system calls 115 is made, the system call wrapper 111 is executed instead.

A system call 115 for obtaining the UID 305 associated with a resource is then intercepted 807. Next, the system call wrapper 111 obtains 809 the UID 305 associated with the resource. In one embodiment, the wrapper 111 obtains the UID 305 by executing the system call 115. As noted, the UID 305 includes, as a consequence of the method 600 of FIG. 6, an indication of a virtual process 101 (e.g., VPID 203).

After the UID 305 is obtained, the system call wrapper 111 removes 811 the VPID 203 by logically ANDing the UID 305 with an appropriate value, e.g., 65535. The UID 305 is then returned 813 to the calling process 301.

FIG. 9 illustrates an alternative system 900 for virtualizing resource ownership. In an alternative embodiment, an indication of the virtual process 101 is not encoded within the UID 305. Rather, after a system call 115 for setting a UID 305 is intercepted, the system call wrapper 111 selects an alternative UID 901 from a set 903 of available (unused) UIDs 305. The set 903 may be implemented using any suitable data structure, such as a table or linked list. The alternative UID 901 may be selected using any convenient method, such as selecting the next available UID 305 in the set 903.

Once the alternative UID 901 is selected, the wrapper 111 creates an association 905 in a translation data structure 907 between the UID 305 specified in the call 115, the alternative UID 901 selected by the wrapper 111, and an indication of the virtual process 101 (e.g., VPID 203), which may be obtained by the wrapper 111 from the virtual process table 127.

After the translation data structure 907 is updated, the wrapper 111 associates the resource with the alternative UID 901. This is accomplished, in one embodiment, by executing the system call 115, specifying the alternative UID 901.

FIG. 9 provides an example of the above-described technique. Suppose that a process 301 having a PID 201 of 1847 attempts to execute the UNIX® setuid( ) system call 115 with a specified UID 305 of 1. As illustrated, the system call wrapper 111 intercepts the call 115 and uses the virtual process table 127 to determine the virtual process 101 (e.g., VPID 203) associated with the calling process 301.

The system call wrapper 111 then selects an alternative UID 901 (e.g., 1003) from a set 903 of available UIDs 305. Thereafter, the wrapper 111 creates an association 905 in the translation data structure 907 between the UID 305 specified in the call 115 (e.g., 1), the alternative UID 901 (e.g., 1003), and the VPID 203 (e.g., 2). Once the translation data structure 907 is updated, the wrapper 111 associates the calling process 301 with the alternative UID 901 by executing, for example, the system call 115.

FIG. 10 illustrates a corresponding system 1000 for intercepting system calls 115 for obtaining the UID 305 or GID 307 associated with a resource. Initially, the system call wrapper 111 intercepts the call 115 (e.g., getuid( ), getgid( ), and stat( )). Thereafter, the wrapper 111 determines the virtual process 101 (e.g., VPID 203) associated with the calling process 301 using a virtual process table 127 or the like.

The system call wrapper 111 then obtains the alternative UID 901 associated with the resource by executing, for example, the system call 115. As described above, the alternative UID 901 is associated with the resource as a consequence of the system 900 illustrated in FIG. 9.

After the alternative UID 901 is obtained, the wrapper 111 accesses the translation data structure 907, looking up the alternative UID 901 and the VPID 203. When an association 905 is found, the corresponding UID 305 is retrieved from the translation data structure 907 and returned to the calling process 301.

An example of the above-described process is shown in FIG. 10. Suppose that a process 301 executes the getuid( ) function, which is intercepted by the system call wrapper 111. In one embodiment, the wrapper 111 executes the getuid( ) function, which returns an alternative UID 901 of 1003. The wrapper 111 also determines the VPID 203 (e.g., 2) associated with the calling process 301 by accessing the virtual process table 127.

The wrapper 111 then accesses the translation data structure 907, looking up an alternative UID 901 of 1003 and a VPID 203 of 2. As illustrated, an association 905 exists, revealing a UID 305 of 1, which is subsequently returned to the calling process 301.

III. Virtualizing Super-User Privileges

As noted above, in UNIX® and related operating systems, the “super-user” is granted special privileges not available to other users. For example, the super-user can open, modify, or delete the files of other users, as well as terminate other users' processes. Indeed, the super-user can add and delete users, assign and change passwords, and insert modules into the operating system kernel 109.

Implementing super-user privileges in an operating system 117 including multiple virtual processes 101 presents numerous challenges. For example, each virtual process 101 should be allowed to have a user who is granted super-user-like powers, e.g., the ability to add and delete users of the virtual process 101, access files 303 of any user of the virtual process 101, terminate processes 301 associated with the virtual process 101, and the like.

However, if a user of each virtual process 101 were given full super-user privileges, a super-user of one virtual process 101 could access the files 303 of a user of another virtual process 101. Similarly, a super-user of one virtual process 101 could terminate the processes 301 associated with a user of another virtual process 101. Indeed, a super-user of one virtual process 101 could obtain exclusive access to all system resources, effectively disabling the other virtual processes 101. Clearly, granting a user of each virtual process 101 full super-user privileges would seriously compromise system security, entirely removing the illusion that each virtual process 101 is running on a dedicated host computer.

As illustrated in FIG. 11, the present invention solves the foregoing problems, in one embodiment, by designating a plurality of virtual super-users 1101, typically one per virtual process 101. A virtual super-user 1101 has many of the privileges of an actual super-user with respect to his or her own virtual process 101. For example, a virtual super-user 1101 can add and delete users of the virtual process 101, access files 303 of any user of the virtual process 101, terminate processes 301 associated with the virtual process 101, and the like. However, a virtual super-user 1101 cannot, for instance, add or delete users of other virtual processes 101, access the files 303 of users of other virtual processes 101, or terminate the processes 301 associated with other virtual processes 101.

In one embodiment, a virtual super-user 1101 is designated by assigning to a user a virtual super-user identifier (VSUID) 1103. The VSUID 1103 may be assigned by a virtual super-user designation module 1105, which generates a VSUID 1103 for each virtual super-user 1101, as described below.

A UID 305 of zero is interpreted by UNIX® and related operating systems as the super-user UID 305. However, assigning a UID 305 of zero to each virtual super-user 1101 would result in the problems discussed above, since an actual super-user has unfettered access to all system resources.

Accordingly, a VSUID 1103 comprises, in one embodiment, a super-user UID 305 (e.g., 0), which has been encoded with an indication of a virtual process 101 (e.g., VPID 203) using the techniques described with reference to FIGS. 5-6. As explained above, a UID 305 may be divided, in one implementation, into two 16 bit portions, with the upper 16 bits used to encode a VPID 203, and the lower 16 bits used to store the original UID 305.

For instance, as shown in FIG. 11, a VPID 203 of 1 is encoded within the upper 16 bits of the VSUID 1103, resulting in a VSUID 1103 of 0x00010000. Likewise, a VPID 203 of 2 results in a VSUID 1103 of 0x00020000. Finally, a VPID 203 of 3 results in a VSUID 1103 of 0x00030000. Of course, those skilled in the art will recognize that the VSUID 1103 may be encoded in various ways without departing from the spirit and scope of the invention.

From the standpoint of the operating system 117, however, the VSUID 1103 is not a super-user UID 305, and does not convey any super-user privileges. For example, a VSUID 1103 of 0x00010000 has a decimal value of 65536, clearly not a UID 305 of zero. Thus, without more, a virtual super-user 1101 would have all of the limitations of a regular user.

Consequently, as shown in FIG. 12, selected system calls 115 are intercepted for performing operations requiring actual super-user privileges, which are nevertheless desirable for a virtual super-user 1101 to perform in the context of his or her own virtual process 101. For example, system calls 115 are intercepted that operate on files 303, e.g., open( ), creat( ), link( ), unlink( ), chdir( ), fchdir( ), symlink( ), readlink( ), readdir( ), access( ), rename( ), mkdir( ), rmdir( ), truncate( ), and ftruncate( ). Of course, those skilled in the art will recognize that the invention is not limited to any particular operating system 117 or terminology.

As noted above, a normal user is typically restricted from opening, deleting, renaming, etc., a file 303 owned by another user. However, a virtual super-user 1101 should appear, in most respects, to be an actual super-user for operations pertaining to his or her own virtual process 101.

Thus, in one embodiment, if a system call 115 is “made” by a virtual super-user 1101 (i.e., by a process 301 owned by a virtual super-user 1101) and pertains to the virtual process 101 of the virtual super-user 1101, then actual super-user privileges are temporarily granted to the virtual super-user 1101 for purposes of the system call 115. This may be accomplished, in one embodiment, by executing an appropriate function, e.g., setuid( ), to assign a UID 305 of zero or other designation of super-user privileges to the calling process 301. After the system call 115 is executed, the super-user privileges may be withdrawn by executing the same function to restore the VSUID 1103.

Whether the system call 115 was made by a virtual super-user 1101 may be determined by checking whether the owner of the calling process 301 has a VSUID 1103. Of course, if the system call 115 was not made by a virtual super-user 1101, the wrapper 111 preferably disallows execution of the system call 115. For instance, the wrapper 111 may generate an error message, indicating a privilege violation. Alternatively, the wrapper 111 may simply allow the system call 115 to proceed without granting actual super-user privileges, resulting in the operating system 117 disallowing execution of the system call 115, since the VSUID 1103 does not convey actual super-user privileges.

Whether the system call 115 pertains to the virtual process 101 of the virtual super-user 1101 may be determined by checking whether the system resource(s) affected by the system call 115 relate to the virtual process 101 of the virtual super-user 1101. For example, with respect to system calls 115 that affect processes 301 (such as kill( )), the virtual process table 127 may be checked to determine whether the process 301 has an association 129 with the virtual process 101 of the virtual super-user 1101. Similarly, in one embodiment, each virtual process 101 has a distinct file system, allowing the wrapper 111 to easily determine whether a file 303 referenced by the call 115 is associated with the virtual process 101 of the virtual super-user 1101.

As shown in FIG. 12, suppose that a process 301 owned by a virtual super-user 1101 attempts to execute the open( ) system call 115 in order to open another user's file 303, which is nevertheless associated with the virtual process 101 of the virtual super-user 1101. The virtual process 101 (e.g., VPID 203) may be determined, in one embodiment, by referencing the virtual process table 127 using the PID 201 of “3942.”

Since the file 303 pertains to the virtual process 101 of the virtual super-user 1101, the system call wrapper 111 temporarily grants actual super-user privileges to the virtual super-user 1101. In the illustrated embodiment, this is accomplished by executing an appropriate system call 1201 (e.g., in UNIX®, the setuid( ) function with a UID 305 of zero). The system call 115 is then executed, after which the wrapper 111 withdraws the actual super-user privileges 1101 by executing, for example, an appropriate system call 1203 (e.g., in UNIX®, the setuid( ) function with the original VSUID 1103 of the virtual super-user 1101). This approach grants super-user privileges on a call-by-call basis.

Thus, a virtual super-user 1101 may perform an operation for which actual super-user privileges are required, without granting the virtual super-user 1101 unfettered access to all of the system's resources. This allows each virtual process 101 to have at least one system administrator with limited super-user-like powers, while maintaining the illusion that each virtual process 101 is running on a dedicated host computer.

Other system calls 115 that may be intercepted include system calls 115 for terminating a process 301. In UNIX®, the kill( ) system call 115 allows a user to terminate one or more processes 301. For example, executing the kill( ) system call 115 with a specified process 301 (e.g., PID 201) terminates that process 301. Executing the kill( ) system call 115 with an argument of −1 results in the termination of all of the user's processes 301. An argument of less than −1 results in the termination of all of the processes 301 associated with a group (e.g., GID 307, where the GID value is equal to the absolute value of the argument).

As noted above, a super-user may terminate any system process 301. Thus, if the super-user specifies a PID 201, the corresponding process 301 will be terminated. Likewise, if the super-user specifies a negative GID 307, the processes 301 belonging to the specified group are terminated. If, however, the super-user specifies an argument of −1, all processes 301 other than those with PID 201 of 0 or 1 are terminated.

In one embodiment, it is desirable for a virtual super-user 1101 to be able to terminate processes 301 associated with his or her virtual process 101. Accordingly, the system call wrapper 111 intercepts system calls 115 for terminating processes 301 (e.g., kill( )).

Where a virtual super-user 1101 attempts to terminate a specific process 301 associated with his or her virtual process 101, the wrapper 111 proceeds as discussed above with reference to FIG. 12. In other words, the wrapper 111 grants temporary actual super-user privileges to the calling process 301 and allows execution of the system call 115.

However, as shown in FIG. 13, where the system call 115 specifies a negative parameter, the wrapper 111 proceeds differently. Since the powers of virtual super-user 1101 should be limited to his or her virtual process 101, a kill( ) system call 115 with an argument of −1 results only in the termination of processes 301 associated with the virtual process 101. Thus, in one embodiment, a kill(−1) system call 115 “pertains” to the virtual process 101 by definition.

In one embodiment, the system call wrapper 111 iterates through the virtual process table 127, terminating all processes 301 associated with the virtual process 101. Thus, a kill(−1) system call 115 operates in the manner expected, maintaining the illusion that the virtual process 101 of the virtual super-user 1101 is executing on a dedicated host machine.

Likewise, in the case of an argument of less than −1, denoting a GID 307, the wrapper 111 cycles through all of the processes 301 associated with the virtual process 101 of the virtual super-user 1101 and determines whether each such process 301 corresponds to the specified group (e.g., GID 307). If so, those processes 301 are terminated in the manner discussed above.

As an example, as shown in FIG. 13, suppose that a process 301 is associated with a virtual process 1 (e.g., having a VPID 203 of 1). The process 301 is owned by a virtual super-user 1101 by virtue of the VSUID 1103 (e.g., 0x00010000), and pertains to the virtual process 101 by definition. Accordingly, the wrapper 111 grants temporary actual super-user privileges to the calling process 301 by executing the system call 1201.

Thereafter, the wrapper 111 iterates through the virtual process table 127, identifying each process 301 (e.g., PIDs 3942 and 4400) associated with a VPID 203 of 1. System calls 115 (e.g., kill(3942), kill (4400)) are then made to terminate each of the identified processes 301, after which the actual super-user privileges are withdrawn by executing the system call 1203.

A variety of other system calls 115 may be intercepted within the scope of the invention in order to grant limited super-user privileges to a virtual super-user 1101. Those skilled in the art will know how to apply the above-described techniques in the context of these other system calls 115.

In some instances, it is desirable to prevent a virtual super-user 1101 from executing certain system calls 115 altogether. For example, in UNIX®, the insmod( ) and rmmod( ) functions allow a super-user to insert modules into, and remove modules from, the operating system kernel 109. Giving such powers to a virtual super-user 1101 could seriously compromise system security, allowing the virtual super-user 1101 to alter the basic functionality of the operating system 117.

In one embodiment, a virtual super-user 1101 is prevented from executing a system call 115 for which actual super-user privileges are required by simply not intercepting the call 115. Since the VSUID 1103 is not a super-user UID 305, the operating system 117 will automatically reject an attempt by a virtual super-user 1101 to execute, for example, the insmod( ) call 115.

In an alternative embodiment of the invention, a virtual super-user 1101 is not designated by assigning a VSUID 1103, as discussed above. Rather, a virtual super-user 1101 is simply assigned a UID 305 as in the case of other users. Thereafter, the assigned UID 305 is stored in a virtual super-user list 1401 or other suitable data structure, as illustrated in FIG. 14, together with an indication of the virtual process 101 (e.g., VPID 203). Accordingly, when selected system calls 115 are intercepted for which actual super-user privileges are required, a user may be identified as a virtual super-user 1101 by consulting the virtual super-user list 1401.

Since virtual super-users 1101 in this embodiment are given regular UIDs 305, the possibility of conflicts between virtual processes 101 arises. However, such conflicts may be resolved using the techniques described in FIGS. 9-10, i.e. intercepting system calls 115 for setting a UID 305 of a resource and assigning an alternative UID 901. Thus, virtual super-users 1101 of different virtual processes 101 may appear to share the same UID 305 without conflict.

FIG. 15 summarizes the above-described techniques. A method 1500 for virtualizing super-user privileges has two phases, preparation and operation. The preparation phase begins by loading 1501 a system call wrapper 111 into the operating system 117. Thereafter, copies are made 1503 of pointers 114 to selected system calls 115 for performing operations for which actual super-user privileges are required, which are nevertheless desirable to be performed by a virtual super-user 1101 with respect to his or her own virtual process 101 (e.g., open( ), kill( ), etc.). The pointers 114 are then replaced 1505, in one implementation, by pointers 118 to the system call wrapper 111. Thus, when one of the selected system calls 115 is made, the system call wrapper 111 is executed instead

During the operation phase, a system call 115 is intercepted 1507 by the system call wrapper 111. Thereafter, the wrapper 111 determines 1509 whether the call 115 was “made” by a virtual super-user 1101 (i.e. by a process 301 owned by a virtual super-user 1101). If not, the system call 115 is disallowed 1511, and the method 1500 ends.

If, however, the call 115 was made by a virtual super-user 1101, a determination 1513 is made whether the call 115 pertains to the virtual process 101 of the virtual super-user 1101. If not, the call 115 is disallowed, and the method 1500 ends.

If, however, the call 115 pertains to the virtual process 101 of the virtual super-user 1101, actual super-user privileges are granted to the virtual super-user, after which the system call 115 is executed 1517. Finally, the actual super-user privileges are withdrawn 1519, and the method 1500 ends.

In view of the foregoing, the present invention offers numerous advantages not available in conventional approaches. For example, super-user privileges are virtualized in an operating system 117 including multiple virtual processes 101, such that a virtual super-user has the power to perform traditional system administrator functions with respect to his or her own virtual process 101, but is unable to interfere with other virtual processes 101 or the underlying operating system 117. Thus, each virtual process 101 can have a virtual super-user 1101, while preserving the illusion that the virtual processes 101 are running on dedicated host machines.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming of the modules, features, attributes or any other aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names or formats. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1. A computer-implemented method for virtualizing super-user privileges in a computer operating system including multiple virtual private servers, the method comprising:

associating a user with a first virtual private server, the first virtual private server comprising a first plurality of actual processes executing within the same operating system as a second plurality of actual processes comprising a second virtual private server;

designating the user as a virtual super-user;

intercepting a call to the operating system for which actual super-user privileges are required, the call made by a process located in the operating system, the process owned by the user, wherein intercepting the call to the operating system comprises:

loading a system call wrapper;

saving a pointer to the call to the operating system, wherein the pointer to the call to the operating system comprises a system call vector; and

replacing the pointer to the call to the operating system with a pointer to the system call wrapper, such that the system call wrapper is executed when the call to the operating system is invoked; and

in response to the intercepted call to the operating system pertaining to the first virtual private server:

granting actual super-user privileges to the user; and

allowing execution of the call to the operating system.

2. A computer program product for virtualizing super-user privileges in a computer operating system including multiple virtual private servers, the computer program product comprising a computer-readable medium storage device and computer program code encoded on the medium storage device for:

associating a user with a first virtual private server, the first virtual private server comprising a first plurality of actual processes executing within the same operating system as a second plurality of actual processes comprising a second virtual private server;

designating the user as a virtual super-user;

intercepting a call to the operating system for which actual super-user privileges are required, the call made by a process located in the operating system, the process owned by the user, wherein intercepting the call to the operating system comprises:

loading a system call wrapper;

saving a pointer to the call to the operating system, wherein the pointer to the call to the operating system comprises a system call vector; and

replacing the pointer to the call to the operating system with a pointer to the system call wrapper, such that the system call wrapper is executed when the call to the operating system is invoked; and

granting actual super-user privileges to the user, and allowing execution of the call to the operating system, in response to the intercepted call to the operating system pertaining to the first virtual private server.

3. A system for virtualizing super-user privileges in a computer operating system including multiple virtual private servers, the system comprising:

means for associating a user with a first virtual private server, the first virtual private server comprising a first plurality of actual processes executing within a same operating system as a second plurality of actual processes comprising a second virtual private server;

means for designating the user as a virtual super-user;

means for intercepting a call to the operating system for which actual super-user privileges are required, the call made by a process executed by the operating system, the process owned by the user, wherein the means for intercepting the call to the operating system is configured to:

load a system call wrapper;

save a pointer to the call to the operating system, wherein the pointer to the call to the operating system comprises a system call vector; and

replace the pointer to the call to the operating system with a pointer to the system call wrapper, such that the system call wrapper is executed if the call to the operating system is invoked; and

means for granting virtual super-user privileges to the user and allowing execution of the call to the operating system in response to the intercepted call to the operating system pertaining to the first virtual private server, wherein a virtual super-user has a subset of the privileges of an actual super-user but a superset of the privileges of a user other than the actual super-user.

4. A method performed by a computing system having a processor and memory for virtualizing user privileges in a computer operating system including multiple virtual private servers, the method comprising:

associating a first user with a first virtual private server, the first virtual private server comprising a first plurality of actual processes executing within a same operating system as a second plurality of actual processes comprising a second virtual private server;

associating an identifier with the first user wherein the first user owns a first set of resources;

associating a second user with the second virtual private server;

associating the identifier with the second user wherein the second user owns a second set of resources that is different from the first set of resources;

intercepting a call to the operating system that retrieves privileges for users, the call made by a process associated with the first virtual private server, and

in response to the intercepted call to the operating system, determining that the process is permitted to access the first set of resources but is not permitted to access the second set of resources.

5. The method of claim 4, wherein intercepting the call to the operating system comprises:

loading a system call wrapper;

saving a pointer to the call to the operating system, wherein the pointer to the call to the operating system comprises a system call vector; and

replacing the pointer to the call to the operating system with a pointer to the system call wrapper, such that the system call wrapper is executed if the call to the operating system is invoked.

6. The method of claim 4 wherein the call to the operating system indicates to take an action on a resource owned by the first user but not the second user.

7. The method of claim 4 wherein the identifier is a user identifier.

8. The method of claim 4 further comprising encoding the user identifier with a virtual process identifier.

9. The method of claim 8 wherein the encoding includes shifting the virtual process identifier by a specified number of bits and then applying a logical OR operation to a result of the shifting with the user identifier.

10. The method of claim 4 wherein the identifier is a group identifier.

11. The method of claim 10 further comprising encoding the group identifier with a virtual process identifier.

12. The method of claim 11 wherein the encoding includes shifting the virtual process identifier by a specified number of bits and then applying a logical OR operation to a result of the shifting with the group identifier.

13. A computer-readable storage device storing computer-executable instructions that, when executed, perform a method for virtualizing user privileges in a computer operating system including multiple virtual private servers, the method comprising:

associating a first user with a first virtual private server, the first virtual private server comprising a first plurality of actual processes executing within a same operating system as a second plurality of actual processes comprising a second virtual private server;

associating an identifier with the first user wherein the first user owns a first set of resources;

associating a second user with the second virtual private server;

associating the identifier with the second user wherein the second user owns a second set of resources that is different from the first set of resources;

intercepting a call to the operating system that retrieves privileges for users, the call made by a process associated with the first virtual private server, and

in response to the intercepted call to the operating system, determining that the process can access the first set of resources but not the second set of resources.

14. A system for virtualizing user privileges in a computer operating system including multiple virtual private servers, the system comprising:

means for associating a first user with a first virtual private server, the first virtual private server comprising a first plurality of actual processes executing within a same operating system as a second plurality of actual processes comprising a second virtual private server;

means for associating an identifier with the first user wherein the first user owns a first set of resources;

means for associating a second user with the second virtual private server;

means for associating the identifier with the second user wherein the second user owns a second set of resources that is different from the first set of resources;

means for intercepting a call to the operating system that retrieves privileges for users, the call made by a process associated with the first virtual private server, and

means for determining, in response to the intercepted call to the operating system, that the process can access the first set of resources but not the second set of resources.