Abstract:
Users provide their standard username and password and are authenticated to the system. The system then determines from an object set, such as a container hierarchy, whether the user should have special administrative privileges for any of the resources on the machine to which they are logging in. These administrative privileges can be determined from configurable sets of pre-existing relationships between the user and resources on the system, stored within the object set. If the user is an administrator, then the system sets the UID number for that user to the UID number for administrator users. The system can even be configured to set the administrative UID to be the UID for the super-user “root” (typically, zero). If the user has no administrative privileges, the system sets the UID number for that user to the user&#39;s standard UID number.

Description:
RELATED APPLICATION DATA 
     This application is a continuation-in-part of commonly assigned, U.S. patent application Ser. No. 11/018,514, titled “Method Binding Network Administrators as the Root User on Linux”, filed Dec. 20, 2004, now abandoned, which is hereby incorporated by reference for all purposes. 
    
    
     FIELD OF THE INVENTION 
     This invention pertains to resource access, and more particularly to allowing users root access to resources based on the resource requested. 
     BACKGROUND OF THE INVENTION 
     Traditional computer operating systems are designed to recognize different levels of authority to use the computer. A typical computer operating system recognizes two such levels. The first level, which can be called the root or administrator level, allows the user to make any changes he or she wants to the computer. Changes that affect multiple users are typically reserved to administrative users, because of the potential to impact multiple users in a negative manner. For example, administrative users are typically reserved the right to install device drivers, and to configure accounts for new users. The second level is the level assigned to most typical users. These users are limited in what they can do. Essentially, regular users can make changes that affect their personal files, including granting other users access to their files, but otherwise cannot make changes. Depending on the operating system, some computers recognize other intermediate levels, which grant some users rights that are similar to administrative rights, but are not as broad in scope (or are more limited in number). 
     While this structure generally works very well, it does have limitations. For example, sometimes it is desirable to let users have control over particular resources (e.g., one application), as if they were administrative users, but limit their control over other resources (e.g., another application). With the structure described above, this level of control is not possible. If a user is an administrative user, they can access every resource just like any other administrative user; if a user is a limited user, they can access every resource only to the extent other limited users can do so. 
     Accordingly, a need remains for a way to give users levels of access to resources that depends on the resource, to address these and other problems associated with the prior art. 
     SUMMARY OF THE INVENTION 
     The invention is a method and apparatus for performing authentication of users. When a user requests access to a resource, such as an application, the system attempts to authenticate the user. Assuming the user is successfully authenticated, the system determines if the user is authorized to access the resource as an administrator. If the user is authorized to access the resource as an administrator, then the system assigns the access attempt an effective user ID (eUID) appropriate for an administrative user. Otherwise, the system determines the user&#39;s user ID (UID) and assigns that value to the eUID for the access. 
     The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a machine equipped to provide administrator access to resources, according to an embodiment of the invention. 
         FIG. 2  shows the object set of  FIG. 1  constructed as a container hierarchy, the object set indicating which resources a user can access as an administrator, according to an embodiment of the invention. 
         FIG. 3  shows the machine of  FIG. 1  connected via a network to other computers, according to an embodiment of the invention. 
         FIG. 4  shows the user being granted different levels of access to different resources the machine of  FIG. 1 , according to an embodiment of the invention. 
         FIGS. 5A-5B  show a flowchart of the procedure used by the machine of  FIG. 1  to authenticate users and of the machine, according to an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       FIG. 1  shows a machine equipped to provide administrator access to resources, according to an embodiment of the invention. In  FIG. 1 , machine  105  is shown as including computer  110 , monitor  115 , keyboard  120 , and mouse  125 . A person skilled in the art will recognize that other components can be included with machine  105 : for example, other input/output devices, such as a printer (not shown). In addition,  FIG. 1  does not show some of the conventional internal components of machine  105 ; for example, a central processing unit, memory, etc. 
     To support user authentication and access control, machine  105  includes various elements. Receiver  130  is responsible for receiving a request from a user process to access a resource, such as resource  135 . Object set  140  includes information about users and resources, including which users are considered administrative users of which resources. Authenticator  145  is responsible for performing the authentication of the user. Determiner  150  determines if the user is considered an administrative user of the resource. UID determiner  155  is responsible for determining the user&#39;s UID, if the user is not an administrator of the resource. And permission setter  160  is responsible for setting the user&#39;s permission level associated with the use of the resource. 
     Now that the elements of  FIG. 1  have been introduced, they can be discussed in greater detail. Receiver  130  is responsible for receiving a user&#39;s request to access a resource. As an example of a type of request, a user might attempt to establish a shell to log in to a server. Or the request might be to access a web based enterprise management (WBEM) server. Or, the application might be a request to access a file. A person skilled in the art will recognize other possible types of requests that can be received by receiver  130 . 
     Object set  140 , as mentioned above, stores information about the user and the resource. Object set  140  can be configured in several different ways. One configuration uses a container hierarchy. As shown in  FIG. 2 , object set  140  includes multiple containers. In  FIG. 2 , root container  205  includes two sub-containers: container  210  and container  215 . In  FIG. 2 , container  210  is shown as including user object  220 , and container  215  is shown as including resource objects  225  and  230 . 
     Although  FIG. 2  shows only two containers, a person skilled in the art will recognize that there can be any number of containers, and they can be in any configuration. For example, within, say, container  210  there can be another container, in which case the containers are said to be nested. In addition, a container can store objects of any type, containers simply being one type of object. Thus, a single container can store a nested container alongside user objects, resource objects, and any other varieties of object. 
     User object  220  stores information about a particular user. User object  220 , among other data, stores the user&#39;s name (“John”) and his UID (“600”). In addition, user object  220  can store authentication information, such as the user&#39;s password, although authentication is usually handled by authenticator  145  in  FIG. 1 . 
       FIG. 2  also shows link  235 . Link  235  represents the fact that the user named John is considered an administrative user of the machine represented by object  225  (i.e., the file server application). In contrast, because object  220  is not linked to object  230 , the user named John is not considered an administrative user of the WBEM application. 
     Although  FIG. 2  represents the fact that the user named John is considered an administrative user of the file server application by link  235 , a person skilled in the art will recognize that there are many different ways in which a user object can be identified as an administrative user for an application. For example, user object  220  can have a list (either part of user object  220  or linked to user object  220 ) of applications for which the user named John is to be considered an administrative user. Or, object  225  can include a list (either part of object  225  or linked to object  225 ) that identifies users who are to be considered administrative users of the application: such a list can be termed a “white list”. Or, object  225  can include a list (either part of object  225  or linked to object  225 ) of users who are not to be considered administrative users of the application: such a list can be termed a “black list”. The white list and black list can be combined with other features of the system, or can stand by themselves. For example, the system can assume that only administrative users of the system can be administrative users. Thus, if a user is not an administrative user, the system can automatically assume the user is not an administrative user, and not bother to check the list. But if the user is an administrative user, the system can check the appropriate list to determine if the user is entitled to administrative access to the application. 
     Returning to  FIG. 1 , authenticator  145  performs authentication of the user. Authentication can be performed using any desired authentication technique, and any desired authentication system. For example, authentication can be performed using, among other alternatives, the Lightweight Directory Access Protocol (LDAP), implemented as a Linux® User Management (LUM) module. (Linux is a registered trademark of Linus Torvalds.) In a Linux system, the authentication module often uses Pluggable Authentication Module (PAM). A PAM LDAP module is just one of the many PAM modules available; a person skilled in the art will recognize that other authentication modules can be substituted for the PAM LDAP module. Further, LUM is a specific instance of a PAM LDAP module; a person skilled in the art will recognize that there are other implementations of a PAM LDAP module that can be substituted for the LUM. 
     Determiner  150  is responsible for determining whether the user is entitled to administrative access to the resource. As discussed above with reference to  FIG. 2 , object set  140  can indicate whether the user is entitled to administrative access in a variety of different ways. Provided that it is known how object set  140  stores information about which users are entitled to administrative-level access, determiner  150  can be easily configured to access this information for use by the system. 
     UID determiner  155  is responsible for determining the UID of the user. In one embodiment, all administrative users use a single administrative level access to the system. For example, in some Linux systems, all administrative users use a single username and password. This administrative username is associated with an administrative UID; all other usernames are assigned other UIDs, which are not considered administrative UIDs. For such a system, UID determiner  155  would determine the UID based on the username provided to log in to the system. If the user used the administrative username, then the administrative user object (there would be at most one for each machine) in object set  140  would be accessed, and the administrative UID returned by UID determiner  155 . But if the user logged in using a non-administrative username, then UID determiner  155  would locate the appropriate user object in object set  140 , and determine the user&#39;s UID from that object. 
     In other embodiments, it is possible for multiple users all to be administrative users, without sharing a common username and password. For example, commonly assigned U.S. patent application Ser. No. 11/018,514, titled “Method Binding Network Administrators as the Root User on Linux”, filed Dec. 20, 2004, hereby incorporated by reference, describes a way to permit users to be treated as administrative users without sharing a single administrative username and password. In this embodiment, UID determiner  155  determines the UID of the user from the user&#39;s object in object set  140 , but upon recognizing that the user is an administrative user, can use the administrative UID. 
     Finally, permission setter  160  is responsible for setting the appropriate permission level to access the resource. Where the permission level is set using UIDs, permission setter  160  can include eUID setter  165  to control the permissions. An effective UID (eUID) provides a way to change the effective operation of the system, without actually changing the UID for the session. For example, the user can be given access to the resource with his or her normal UID, but with an effective UID of the administrative user. By using the eUID in this manner, the user can be given administrative-level access to the resource, even though the UID being used is the user&#39;s normal (i.e., non-administrative) UID. 
       FIG. 3  shows machine  105  connected to network  305 , the network connecting several other computers. Two computers,  310  and  315 , are shown, but a person skilled in the art will recognize that there can be any number of machines connected via the network. Computer  310  is shown including user process  320 , a process for a user named John. This situation can arise in several ways. For example, computer  310  might be a workstation, which John is using. Or, computer  310  might be a server carrying out some process for the user John, who is using another computer to request the process. (In this latter situation, the computer used by John is often called a client, but a person skilled in the art will recognize that the terms “client” and “server” should not be interpreted in any way that might limit the varieties of machines in either role.) A person skilled in the art will recognize other ways in which computer  310  might carry out the process on John&#39;s behalf. 
     User process  320  can make a request of resource  135  on machine  105 , even though user process  320  is running on another computer. Assuming that machine  105  is configured to allow remote access to resource  135 , there is no requirement that user process  320  be running on machine  105 . 
     Although  FIG. 3  (and  FIG. 1 ) shows machine  105  and computers  310  and  315  as ordinary computers and network  305  as a typical network, a person skilled in the art will recognize that the equipment can take any desired form. For example, computer  310  might be a personal digital assistant (PDA). Or computer  315  might be a device including an embedded processor. And network  305  can use any desired communication protocol and could be configured as a wired or wireless network, connecting machine  305  and computers  310  and  315  (and possibly other computers) using direct connections, a Local Area Network (LAN), Wide Area Network (WAN), Metropolitan Area Network (MAN), or using a public network, such as the Internet, among other possibilities. If using a wireless network, network  305  might be Bluetooth network or a network offering connectivity using the IEEE 802.11 a/b/g/n standards, among other possibilities. 
     Depending on the configuration of the equipment and the location of the resource in question, a system that embodies the invention can include a single computer (including both resource  135  and user process  320 ), in which case network  305  can be omitted. Or a system embodying the invention can include multiple machines, connected in some manner, with resources and processes distributed among the machine. A person skilled in the art will recognize other possible configurations. 
       FIG. 4  shows the user being granted different levels of access to different resources the machine of  FIG. 1 , according to an embodiment of the invention. In  FIG. 4 , the user named John is running user process  320 . In the course of execution, user process  320  requests access to two different resources: file server  405 , and WBEM  410 . The user named John, and resources  405  and  410  are, of course, both represented by objects in the object set shown in  FIG. 2 . According to the information in the object set of  FIG. 2 , the user named John is entitled to administrative-level access to file server  405 , but not to WBEM application  410 . Accordingly, the eUID for the access attempt to the file server is set to administrative-level access, as shown by permission box  415 , but the eUID for the access attempt to the WBEM application is set to regular access, as shown by permission box  420 . 
       FIGS. 5A-5B  show a flowchart of the procedure used by the machine of  FIG. 1  to authenticate users and of the machine, according to an embodiment of the invention. In  FIG. 5A , at step  505 , the system receives a request from a user process to access a resource. At step  510 , the system accesses the object set. At step  515 , the system authenticates the user using the object set. As discussed above with reference to  FIG. 1 , authentication can take any desired form, and is designed to verify that the user is who he says he is. 
     At step  520  ( FIG. 5B ), the system determines if the user is considered to be an administrator of the resource. If so, then at step  525 , the system sets the effective user ID for the access attempt to indicate administrative-level access. Otherwise, at step  530 , the system determines the user&#39;s normal UID, and at step  535  sets the eUID for the access attempt to the user&#39;s normal UID. 
     It is worth noting that the system can do whatever is appropriate with respect to the UID of the access attempt. For example, if the system requires that the user&#39;s UID be set to root to grant any privileged access to the resource, then if the user is granted administrative-level access, the UID can be set to the administrator. On the other hand, if the system can grant administrative-level access to the resource regardless of the setting of the UID, then the system can set the UID to the user&#39;s normal IUD, even while setting the eUID to grant administrative-level access to the resource. Of course, if the user is to be granted only non-administrative-level access to the resource, then the system will typically set the UID to user&#39;s normal UID. 
     The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention may be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc. 
     The machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciated that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optical, infrared, cable, laser, etc. 
     The invention may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access. 
     Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles. And although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the invention” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments. 
     Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.