This invention pertains to application execution, and more particularly to allowing users to execute an application based on the application requested.
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 applications as if they were administrative users, but limit their control over other applications. With the structure described above, this level of control is not possible. If a user is an administrative user, they can access every application just like any other administrative user; if a user is a limited user, they can access every application only to the extent other limited users can do so.
Accordingly, a need remains for a way to give users levels of access to application that depends on the application, to address these and other problems associated with the prior art.
The invention is a method and apparatus for performing authentication of users. When a user requests to execute an application, the system attempts to authenticate the user. Assuming the user is successfully authenticated, the system determines if the user is authorized to execute the application. This authorization can be determined in different ways, as desired. For example, the system can include a blacklist of users or groups that are to be denied permission to execute the application. Then, even if the user is authenticated, if the user is not authorized to execute the application, the system denies the user permission to execute the application.
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.
Receiver 130 is responsible for receiving a request from a request the user to access an application, such as application 135. Such access is typically a request to execute an application, but a person skilled in the art will recognize that the user might be making some other type of request: for example, to modify a data file that supports execution of the application. Application 135 can be any application, but typically, application 135 is an alternative way to access machine 105 without completely logging in to machine 105.
Authentication module 140 is responsible for authenticating 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, Lightweight Directory Access Protocol (LDAP): for example, with a Linux® operating system User Management (LUM) module. (Linux is a registered trademark of Linus Torvalds.) In a Linux operating system, the authentication module often uses a Pluggable Access Module (PAM), with which LDAP and/or LUM can be used.
To support authentication, object set 145 is used. Object set 145 stores information about users and applications (among other resources that can be represented by objects within object set 145). Object set 145 can be configured in several different ways. One configuration uses a container hierarchy. As shown in
Although
User object 220 stores information about a particular user. User object 220, among other data, stores the user's name (“John”), his user ID (IAD “600”) and his group ID (GID “335”). The UID is a unique ID assigned to the user by the system, and is different from any ID assigned to other users. The GID is a way to group users, and is not necessarily unique to each user. In addition, user object 220 can store authentication information, such as the user's password, although authentication is usually handled by authenticator 140 in
Although user object 220 can store a GID, there can be more than one group to which the user belongs. The GID provides one way to group together users that share some common computer-related element: for example, all users whose home directories lie within a common directory in the file system. Thus, for example, all employees that work in the sales department might have their home directories in a common location within the file system, and might have a common GID. But there are other ways to group together users, which might not have any significance to the computer system. For example, it might make sense to group together all sales managers. Since typically a user has only a single GID, the GID cannot typically be used to represent multiple groups to which the user belongs. Group object 225 provides this alternate way to group users. For example, group object 225 lists three users: John, Mary, and Ana. While
Application object 230 is shown as including list 240. List 240 is a list of users who are to be granted or denied permission to execute the application represented by application object 230. (A person skilled in the art will recognize that the phrase “permission to execute the application” can be interpreted to mean “the ability to execute the application”. In other words, “permission” refers to the user's ability to execute the application.) Whether users are granted or denied permission to execute the application depends on the structure of list 240. For example, list 240 can be a blacklist, identifying users that are to be denied permission to execute the application. Or, list 240 can be a whitelist, identifying the only users that are to be granted permission to execute the application. In addition, a person skilled in the art will recognize other ways to control user access to applications, beyond blacklists and whitelists.
List 240 can identify users in different ways. For example, list 240 is shown as including to IDs: 600 and 512. Assuming that GIDs and UIDs are relatively unique (that is, no GID is the same number as any UID), then list 240 can be a straightforward list of IDs that are to be granted or denied access. (Of course, if GIDs and UIDs are not relatively unique, then list 240 can be modified to store which IDs represent GIDs and which represent UIDs, to achieve the same result.) List can also store group names, to represent groups that are not identified by GIDs. For example, group object 225 is named “Group 1”. If the name “Group 1” were included in list 240, then members of the group represented by group object 225 can be granted or denied permission to execute the application, without individually managing their UIDs. Depending on whether or not the appropriate ID is found in the list, the user can be granted or denied permission to execute the application, as appropriate.
As an example, assume that list 240 represents a blacklist. That is, any user who is represented within list 240 is to be denied permission to execute the application. In addition, to simplify matters, assume that GIDs and UIDs are relatively unique (that is, no number is both a UID for some user and a GID for some group). This last assumption means that ID 600 must identify UID 600, which identifies the user named John. Since John's UID is in list 240, John is to be denied permission to execute the application.
Given that there are many different ways to identify users (through their UIDs, through their GIDs, and through their group memberships), the question arises how to handle these many different ways to identify users. One way to handle this situation is to treat a user as being on the list if any way to identify the user is on the list. Thus, even if a particular user were not include by UID, if their GID was on the list, or if a group to which they belong were on the list, then the user would be treated as if their UID were on the list. Thus, GIDs and groups can be thought of as shorthand representations of the lists of users that share those GIDs and groups.
Although
Returning to
In one embodiment, machine 105 includes a variant of the Linux® operating system. Thus, application 135 would be an application that runs under the Linux operating system. But a person skilled in the art will recognize that embodiments of the invention can be implemented to support other operating systems, provided the other operating systems can support access control to the applications in addition to user authentication.
At step 425 (
One important point in the flowchart shown in
In
If neither the user's UID nor GID are blacklisted, then at step 530 the system determines the groups to which the user is a member. At step 535 (
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® wireless technology, optical, infrared, cable, laser, etc. (The Bluetooth word mark is a registered trademark of the Bluetooth SIG, Inc.)
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.
This application claims priority from commonly-assigned U.S. Provisional Patent Application Ser. No. 60/636,946, titled “Fine Grained Access Control for Linux Services”, filed Dec. 17, 2004, which is hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
4918653 | Johri et al. | Apr 1990 | A |
5664206 | Murow et al. | Sep 1997 | A |
5713024 | Halladay | Jan 1998 | A |
5721824 | Taylor | Feb 1998 | A |
5732212 | Perholtz et al. | Mar 1998 | A |
5748890 | Goldberg et al. | May 1998 | A |
5835777 | Staelin | Nov 1998 | A |
5894571 | O'Connor | Apr 1999 | A |
5901227 | Perlman | May 1999 | A |
5950010 | Hesse et al. | Sep 1999 | A |
5961593 | Gabber et al. | Oct 1999 | A |
6144959 | Anderson et al. | Nov 2000 | A |
6161139 | Win et al. | Dec 2000 | A |
6205579 | Southgate | Mar 2001 | B1 |
6256774 | O'Leary et al. | Jul 2001 | B1 |
6259442 | Britt et al. | Jul 2001 | B1 |
6282711 | Halpern et al. | Aug 2001 | B1 |
6301707 | Carroll et al. | Oct 2001 | B1 |
6324691 | Gazdik | Nov 2001 | B1 |
6353926 | Parthesarathy et al. | Mar 2002 | B1 |
6367075 | Kruger et al. | Apr 2002 | B1 |
6421777 | Pierre-Louis et al. | Jul 2002 | B1 |
6457130 | Hitz et al. | Sep 2002 | B2 |
6460060 | Maddalozzo et al. | Oct 2002 | B1 |
6493871 | McGuire et al. | Dec 2002 | B1 |
6539473 | Hubacher et al. | Mar 2003 | B1 |
6539539 | Larsen et al. | Mar 2003 | B1 |
6606744 | Mikurak | Aug 2003 | B1 |
6615406 | Amberg et al. | Sep 2003 | B1 |
6651085 | Woods | Nov 2003 | B1 |
6725452 | Te'eni et al. | Apr 2004 | B1 |
6728711 | Richard | Apr 2004 | B2 |
6735757 | Kroening et al. | May 2004 | B1 |
6775829 | Kroening | Aug 2004 | B1 |
6799208 | Sankaranarayan et al. | Sep 2004 | B1 |
6892382 | Hapner et al. | May 2005 | B1 |
6928644 | Kroening et al. | Aug 2005 | B1 |
6981028 | Rawat et al. | Dec 2005 | B1 |
7006993 | Cheong et al. | Feb 2006 | B1 |
7013461 | Hellerstein et al. | Mar 2006 | B2 |
7016959 | Dinh et al. | Mar 2006 | B2 |
7051327 | Milius et al. | May 2006 | B1 |
7055149 | Birkholz et al. | May 2006 | B2 |
7093247 | Ashworth et al. | Aug 2006 | B2 |
7143067 | Cheston et al. | Nov 2006 | B1 |
7177859 | Pather et al. | Feb 2007 | B2 |
7181768 | Ghosh et al. | Feb 2007 | B1 |
7185047 | Bate et al. | Feb 2007 | B1 |
7222218 | Dutt et al. | May 2007 | B2 |
7251812 | Jhanwar et al. | Jul 2007 | B1 |
7272815 | Eldridge et al. | Sep 2007 | B1 |
7284243 | Burgess | Oct 2007 | B2 |
7302634 | Lucovsky et al. | Nov 2007 | B2 |
7350075 | Eastham | Mar 2008 | B1 |
7353533 | Wright et al. | Apr 2008 | B2 |
7356679 | Le et al. | Apr 2008 | B1 |
7398480 | Zimniewicz et al. | Jul 2008 | B2 |
7398524 | Shapiro | Jul 2008 | B2 |
7424617 | Boyd et al. | Sep 2008 | B2 |
7478381 | Roberts et al. | Jan 2009 | B2 |
7506337 | Iyer | Mar 2009 | B2 |
7506338 | Alpern et al. | Mar 2009 | B2 |
7539978 | Haddox et al. | May 2009 | B1 |
7546594 | McGuire et al. | Jun 2009 | B2 |
7571427 | Wang et al. | Aug 2009 | B2 |
7574706 | Meulemans et al. | Aug 2009 | B2 |
7577722 | Khandekar et al. | Aug 2009 | B1 |
7853609 | Dehghan et al. | Dec 2010 | B2 |
20010023440 | Franklin et al. | Sep 2001 | A1 |
20010029605 | Forbes et al. | Oct 2001 | A1 |
20020007330 | Kumar et al. | Jan 2002 | A1 |
20020007380 | Bauchot et al. | Jan 2002 | A1 |
20020010757 | Granik et al. | Jan 2002 | A1 |
20020019879 | Jasen et al. | Feb 2002 | A1 |
20020100036 | Moshir et al. | Jul 2002 | A1 |
20020147974 | Wookey | Oct 2002 | A1 |
20020156877 | Lu et al. | Oct 2002 | A1 |
20020162030 | Brezak et al. | Oct 2002 | A1 |
20030014656 | Ault et al. | Jan 2003 | A1 |
20030037107 | Maeda | Feb 2003 | A1 |
20030061202 | Coleman | Mar 2003 | A1 |
20030115292 | Griffin et al. | Jun 2003 | A1 |
20030121024 | Hill et al. | Jun 2003 | A1 |
20030126214 | Oliszewski | Jul 2003 | A1 |
20030131073 | Lucovsky et al. | Jul 2003 | A1 |
20030149749 | Hetherington et al. | Aug 2003 | A1 |
20030172127 | Northrup et al. | Sep 2003 | A1 |
20030182414 | O'Neill | Sep 2003 | A1 |
20030195970 | Dinh et al. | Oct 2003 | A1 |
20030200149 | Gonzalez et al. | Oct 2003 | A1 |
20030217123 | Anderson et al. | Nov 2003 | A1 |
20030221190 | Deshpande et al. | Nov 2003 | A1 |
20040003266 | Moshir et al. | Jan 2004 | A1 |
20040006710 | Pollutro et al. | Jan 2004 | A1 |
20040015831 | Bowhill | Jan 2004 | A1 |
20040015946 | Te'eni et al. | Jan 2004 | A1 |
20040025048 | Porcari et al. | Feb 2004 | A1 |
20040049697 | Edwards, Jr. et al. | Mar 2004 | A1 |
20040102182 | Reith et al. | May 2004 | A1 |
20040196981 | Nakano et al. | Oct 2004 | A1 |
20040205748 | Iyer | Oct 2004 | A1 |
20040254976 | Malik et al. | Dec 2004 | A1 |
20040255291 | Sierer et al. | Dec 2004 | A1 |
20050002057 | Oe | Jan 2005 | A1 |
20050005152 | Singh et al. | Jan 2005 | A1 |
20050081055 | Patrick et al. | Apr 2005 | A1 |
20050097353 | Patrick et al. | May 2005 | A1 |
20050120054 | Shulman et al. | Jun 2005 | A1 |
20050125677 | Michaelides | Jun 2005 | A1 |
20050132179 | Glaum et al. | Jun 2005 | A1 |
20050132349 | Roberts et al. | Jun 2005 | A1 |
20050134896 | Koga | Jun 2005 | A1 |
20050144615 | Chen et al. | Jun 2005 | A1 |
20050235248 | Victoria et al. | Oct 2005 | A1 |
20050246588 | Deng et al. | Nov 2005 | A1 |
20060021065 | Kamperman et al. | Jan 2006 | A1 |
20060047657 | Frieder et al. | Mar 2006 | A1 |
20060059359 | Reasor et al. | Mar 2006 | A1 |
20060090208 | Smith | Apr 2006 | A1 |
20060123101 | Buccella et al. | Jun 2006 | A1 |
20060123414 | Fors et al. | Jun 2006 | A1 |
20060137000 | Isaacson | Jun 2006 | A1 |
20060155838 | Wu et al. | Jul 2006 | A1 |
20060174238 | Henseler et al. | Aug 2006 | A1 |
20060212865 | Vincent et al. | Sep 2006 | A1 |
20060218544 | Chakraborty et al. | Sep 2006 | A1 |
20060230124 | Belfiore et al. | Oct 2006 | A1 |
20060265597 | Carey et al. | Nov 2006 | A1 |
20060277542 | Wipfel | Dec 2006 | A1 |
20070006205 | Kennedy et al. | Jan 2007 | A1 |
20070111726 | Lambert et al. | May 2007 | A1 |
Number | Date | Country |
---|---|---|
2419711 | May 2006 | GB |
Number | Date | Country | |
---|---|---|---|
60636946 | Dec 2004 | US |