WO1999035552A1

WO1999035552A1 - Method for authorising access to execution rights of privileged controls

Info

Publication number: WO1999035552A1
Application number: PCT/FR1998/002889
Authority: WO
Inventors: Gérard Selles; Gérard Sitbon; François Urbain
Original assignee: Bull S.A.
Priority date: 1997-12-30
Filing date: 1998-12-28
Publication date: 1999-07-15
Also published as: FR2773236B1; EP0961961A1; FR2773236A1

Abstract

In a computer system (SYS) comprising at least a group (GP1-GP3) owning privileged controls, said group including at least one respective user (UT1-UT3) having both the respective password (PW1-PW3) for being connected to the system (SYS) and a respective user identifier (IU1-IU3) assigned by an administrator (ADM), a user transmits a request (REQ) including at least one command and accesses a privileged control of another user via his own respective user identifier (IU1-IU3).

Description

Title: Procedure for authorizing access to privileges to execute privileged orders Technical area

The present invention relates to a method for authorizing access to commands or objects on a computer system.

The computer system can be a system whose environment is of the distributed or local type.

The system includes a plurality of users who own privileges to execute privileged commands. The rights include writing, reading from a file and executing a command. The invention is particularly applicable to three categories of users:

- the owner of a file,

- the user group to which the owner belongs, known as the owner group,

- other users, that is to say everyone. These other users may have rights to execute privileged commands and therefore belong to other owner groups,

- and an administrator.

The invention applies to any kind of operating system. The UNIX (registered trademark) operating system is currently the preferred mode of implementing the invention.

The prior art

In general, a file access protection system uses a three-dimensional table, known as a protection matrix, and includes the user, the action, and the purpose of the action. Each element of the array indicates whether or not the user has the right to perform a certain action on a certain object. Privileged commands are assigned to a user. In a system such as UNIX (Trademark), objects are files.

The administrator is responsible for the administration and the smooth running of the system. He is responsible for security backups, file access management. It is also responsible for giving each user a name, a user identifier, and a set of privileges, such as privileges to execute privileged commands on files, etc. Privileges correspond to these responsibilities: he has unrestricted access to all directories and files, to all privileged commands, etc.

To protect access to files, you must be able to identify the requester when he initiates a request, and compare his request with the rights he has on a file. The rights include writing, reading from a file and executing a command. A user has, at a minimum, a name or number, usually called a password, which he gives when he accesses the system. In another registry, a user can activate commands contained in a file owned by another user. For example, the basic UNIX (Trademark) mechanism, known to those skilled in the art, which allows a user to execute a command with the rights of another user is the "su-usemame" command. The term "usemame" is the password or user name identifier of the user whose rights they want to use on privileged orders. During the execution of this command, the real user is no longer the actual user. The user who owns the file becomes the effective user. The user, by invoking the "su-username" command, will have to provide the password of the user who owns the file.

The major problem in such a situation is that, if a user wishes to use the rights of another user, he will have to know not only their own password for logging in to the system, but also the password for that other user. Generally, a user must know a multitude of passwords. Memorizing a password is therefore very difficult. In addition, in some systems, the user is forced to have passwords long enough and meaningless to make them difficult to guess. Remembering a password is even more difficult.

Such a mechanism presents another problem when one wants to withdraw rights on privileged commands granted to a user. Such a maneuver involves periodically changing the passwords of each of the file owner or group owners. Changing this password has repercussions which in no way facilitate its memorization by users, especially when the password is shared by several people. Memorizing a password therefore becomes practically impossible.

This mechanism presents another significant problem. The "su-username" command cannot be used in a command script. Indeed, an order script appears in clear, therefore readable, which means that any person skilled in the art can understand the semantics by reading the text on any medium, paper, computer terminal screen, for example. It would be contrary to the principle of confidentiality to integrate in a script the password of the user to whom belongs the right to execute privileged commands, in the sense that a malicious intruder could obtain this password and use without difficulty the privileged commands of the owner user. The only solution provided by the prior art is to integrate the "usemame" password in the command via the keyboard and only by the person authorized to integrate it. The consequence of such a solution is the impossibility of launching the command script in the absence of the authorized user. In addition, the command "su-username" has the defect of giving a user of this command the right to execute all privileged commands, without selection on the commands from the owner associated with the password "usemame".

There are, at present, other solutions to access security problems. In particular, a basic mechanism used to protect access to files is, among others, that known under the name of security server "Accessmaster" (registered trademark). Applications or functions of the server provide a central and consistent administration of safety for ^the audit and for effective management of user rights. The purpose of consistent administration is to control all users and their access rights. This server contains a complete description of all users and their attributes and privileges. It allows the identification and authentication of users via a password or smart card, controlling access to the workstation according to the rights defined. In this type of mechanism, the database manager that receives a request from a user will interrogate the security server. For this, we use a software interface called API (Application Program Interface) or programming interface provided by the security server.

The problem encountered with this type of mechanism is that there is a mutual authentication mechanism between interfaces. These interfaces are taken into account when designing the components of the application in question. Depending on needs, it happens to enrich privileged orders. This mechanism therefore has the disadvantage of imposing a modification of the software components involved. Summary of the invention

A first object of the invention is to be able to grant users the right to execute privileged commands in a transparent manner while being selective about the allocation of privileges to execute privileged commands.

A second aim is to design a process that does not involve any modification of the software components contained in the system.

A third aim is to improve the security of access to privileged commands.

A fourth aim is the simplicity of use of the method of the invention.

To this end, the subject of the invention is a method of accessing privileges for executing privileged commands in a computer system, said system comprising at least one group owning privileged commands, said group comprising at least one user having both a password for logging into the system and a user identifier assigned by an administrator, said user issuing requests including at least one command, characterized in that it consists, for a user, in accessing a command privileged of another user through his own user identifier.

This results in a computer system comprising at least one group owning the right to execute at least one privileged command, said group comprising at least one user characterized in that it includes a software mechanism for authorizing access to the commands. privileged implementing the method.

The invention will be better understood on reading the following description given by way of example and made with reference to the accompanying drawings. In the drawings:

- Figure 1 is a block diagram of the architecture of a computer system on which the method according to the invention can be applied;

- Figure 2a is an algorithm illustrating an embodiment of the method for allocating privileges for executing privileged commands in the computer system shown in Figure 1;

- Figure 2b is a schematic view of a request and its main parameters according to the present invention; and

- Figure 3 is a table authorizing access to a file illustrating a variant of the method for authorizing privileges to execute privileged commands;

- Figure 4 is a block diagram of the architecture of a computer system whose environment is distributed on which the method according to the invention can be applied;

- Figure 5 is a view of the links existing between each node;

- Figure 6 is a view of an authorization table for access to privileged commands.

To simplify the description, in the drawings the same elements have the same references.

Description of an exemplary embodiment

Figure 1 shows an example of a SYS computer system. In this figure, three groups GP1, GP2 and GP3 are represented, owners of privileged commands The invention is not limited to three owner groups but applies to any number. It will be assumed, in the following description, that an owner group comprises at least one user. In the example illustrated, each group GP1 , GP2 and GP3 includes a respective user UT1, UT2 and UT3 The privileged commands include, as indicated in the introduction, writing, reading a file and executing a command

This system includes an ADM administrator, as defined in the introduction. This administrator assigns rights to privileged commands as well as access rights to files or directories to these different users UT1, UT2 and UT3 Each user UT1 -UT3 has a respective user identifier IU1, IU2 and IU3 The user identifier is assigned by the ADM administrator of the system and allows the system to recognize implicitly the user connected to the system Users are also assigned a password PW1, PW2 and PW3 for connection to the system without which the user cannot access the system. In other words, it is the knowledge of the password which authorizes connection to the system In concrete terms, a user, for example UT1, connects to the SYS system by means of his password PW1 Once the connection established, the system authenticates this same user UT1 by means of its user identifier IU1 The user UT1, has, from this moment, the possibility of launching a request REQ. This request includes parameters as well as CON content including a request to execute DCP privileged commands

The problem, as mentioned in the introduction to the description, is the difficulty for the user UT1 owner or belonging to a group owner of privileged commands to access commands belonging to another group owner than his. Indeed, the mechanisms existing are poorly adapted in terms of memorizing passwords and complicate the task of user UT1 who wishes to use the rights privileged commands from a file owner, for example UT2. In addition, the confidentiality of a password shared by several people is problematic.

The method according to the invention consists in that a user, for example UT1, accesses a privileged command from another user, for example UT2, by means of his own user identifier IU1. To this end, the method of the invention is implemented by means of a software mechanism for authentication and authorization to access privileges for executing privileged commands, the operation of which appears clearly from the figure. 2a.

We will now describe, with reference to FIGS. 2a and 2b, an algorithm comprising the different steps of the method in accordance with the present invention, and a schematic view of the main parameters that comprise a REQ request.

The method conventionally begins in a step 10 in which a user, for example UTÏ, initiates a REQ request. During a step 20, the REQ request originating from a user is intercepted. The method of the invention consists in verifying, in step 30, that the request REQ sent by the user UT1 is a request for execution of privileged commands DCP. To this end, a characteristic of the invention is that each REQ request comprises a parameter PRC characteristic of a request for execution of privileged commands as illustrated in FIG. 2b. The process is activated via the PRC parameter. Activation consists in verifying that the REQ request contains the information necessary to authorize user UT1 to access a privileged command. The method consists in processing only the requests whose content is a request for execution of privileged commands. In the case of a request not containing the parameter PRC, the method results in a step 40. During this step 40, the method remains inactive and does not process the request REQ. Step 40 then indicates the end of the process. Yes the REQ request includes the PRC parameter, the process continues and consists in verifying that this REQ request includes the information necessary to authorize a user to access the privileged commands of another user. To this end, the method consists in breaking down the request REQ in step 50 and in extracting therein the request for execution of a privileged command DCP which the user UT1 wishes to acquire. The mechanism furthermore implicitly knows the user identifier IU1 of the user UT1.

The mechanism includes tables in which we find the identifier of the users authorized to execute privileged commands. The mechanism also includes tables comprising all of the commands for authorizing the execution of privileged commands. The method consists in verifying, in step 70, that the user identifier IU1 of the user UT1 is listed in the tables. If the identifier of the user IU1 is not listed in the tables, the user is not authorized to execute privileged commands and the method consists in transmitting an error message, in step 60, to report on the situation. This error message is unique in order to give no indication of the cause of the failure during an attempted intrusion by any individual and especially by a malicious individual. Otherwise, corresponding to step 80, that is to say when the user identifier is listed in the tables, another analysis is performed. During this analysis, it is checked that the DCP command resulting from the REQ request is listed in the tables. If the command is not listed, an error message identical to that of step 60 is sent to the user. Otherwise, in step 90, we have all the information necessary to authorize a user, UT1, to access the privileged commands of another user. From this instant, the method consists in authorizing, in a transparent manner, the user UT1 to use rights on privileged commands on the account of another user. A user UT1 can launch privileged commands belonging to an owner with the rights of this owner, for example UT2. In other words, in step 90, writing and / or reading and / or executing of the file bearing the name of the command is authorized. In step 100, the method consists in executing the transformation of the initial request into an actual request. The initial request corresponds to the REQ request issued and which has not undergone any processing through the mechanism. The actual request corresponds to the request that has been processed.

It should be noted that the two steps 70 and 80 are the necessary and sufficient conditions to authorize a user to execute privileged commands belonging to another user. The direction of execution of steps 70 and 80 is indifferent.

Figure 2b illustrates the parameters making up an initial REQ request. This request includes in its CON content the request for privileges to execute DCP privileged commands that a user wishes to acquire. Preferably, the DCP request contains a request to execute a single command. The request thus includes, as mentioned previously, a PRC parameter characteristic of a request for execution of privileged commands. According to a variant of the method of the invention, this parameter PRC is preferably a prefix which is added to the other parameters that comprise the request REQ. The purpose of this prefix is to easily identify a request including a request to execute a privileged command and activate the process.

FIG. 3 illustrates an exemplary embodiment of the tables used during steps 70 and 80 of FIG. 2a. These tables can, in one example, be represented by a three-dimensional table as defined in the introduction to the description. Preferably, these tables can have a tree structure with a single node called PRC and which corresponds to the PRC prefix of the request. Each node that is not a leaf in the file system structure is a file directory. Under the PRC directory, there are two directories. A first REG directory has the role the recording of privileged orders. The second DIST directory will be described later in the description.

Under the REG directory, there are privileged command description files. In the example illustrated, the description files printA and printB are shown. Preferably, a privileged command is associated with a description file. Each file contains a data structure which contains the operations to be carried out during the transformation of the initial REQ request into an actual request. The printA and printB description files include parameters, among others. These parameters include the owner group to which the privileged command belongs as well as the users authorized to use this privileged command. The role of these files is to transform the initial REQ request, issued by a user, into an actual request. The operations are inter alia, the acquisition of the required rights, the change or not of environment in the case where the systems belong to different environments, the propagation of environment variables like the variables DISPLAY or LANG, known to the skilled in the art, between the departure and arrival environments, call logging, etc.

Another DIST directory is used. The role of this directory is to register users authorized to use privileges to execute privileged commands. This directory is attached to the same unique node

PRC. The DIST directory contains, for example, the identifier IU1-IU3 of the users authorized to execute privileged commands. In another example, this DIST directory can simply contain the names of the users UT1-UT3 authorized to execute privileged commands. Preferably, the DIST directory is made up of named directories, for example, IU1 or IU2 corresponding to the identifier of the users authorized to execute privileged commands. Finally, each directory bearing the name of a user corresponds to at least one file bearing, for example, the name of the command for which it is authorized to be executed. In the example illustrated, we named a printA file associated with the IU1 directory associated with the user UT1. In other words, the presence of the identifier IU1 under the directory DIST means, first of all, that the user UT1 has obtained execution execution rights on privileged commands. Then, the presence of the printA file under the IU1 directory means that it has obtained execution rights for the printA command. From this moment, if the user is authorized to execute privileged commands, the process consists in verifying that this printA command has been saved in the REG directory. If this is the case, the printA file is executed and transforms the initial REQ request into an actual request. The method consists in checking under the REG directory, in the description file corresponding to the printA command, that the user in question UT1 is authorized to execute this command. All these steps are carried out transparently for user UT1. If user UT1 is authorized to execute the printA privileged command, the actual request is launched. From this moment, the real user UT1 is no longer the effective user. The effective user is the user UT2 who owns the rights to execute privileged commands.

The present invention is applicable to computer systems whose environment is of the distributed type or of the local type.

In general, a computer system whose environment is of the distributed type is an environment which operates by means of at least two operating systems linked together via a local type network of LAN type (Local Area Network) or long distance WAN (Wide Area Network) or internet type. On the other hand, a computer system whose environment is of the local type is a computer system which operates by means of a single operating system.

In a computer system whose environment is distributed, several nodes are connected to each other. Such a system is shown in Figure 4. In the illustrated example, the system includes three N1-N3 nodes. Each node N1-N3 can comprise at least one respective owner group GP1-GP3 including at least one respective user UT1-UT3, as defined above. In the example illustrated, user UT1 can launch an APP1 application. By definition, this APP1 application is of the software type. In the example illustrated, the node N1 comprises an application client which is the application APP1. The node N2 includes an SAP application server.

These three nodes N1-N3 are interconnected via a RES network, the communication protocol of which can be of the TCP-IP (Transport Control Protocol - Internet Protocol) type known to those skilled in the art. A set of software layers, not illustrated, is interposed between a node N1 -N3 and the network RES. This set of software layers is based on the OSI (Open System Interconnection) model of the ISO (International Organization for Standardization) layer architecture or the TCP-IP model, known to those skilled in the art.

Each node includes specific API type programming interfaces for accessing a service known to those skilled in the art. By definition, this programming interface is a set of tools made available to programmers intended to standardize the user interface, program control and control of data sent over a network. Developers, when creating software, will search the API programming interface for names of menus and commands, window and dialog models. An API programming interface is generally associated with a library.

Preferably, access rights management is carried out through a centralized access rights management unit. According to this variant, the tables are included on a single node N3. In the example illustrated, all the tables are included in a BDD database. This BDD database is linked to a SERV database scent. The APP1 application client, the SAP application server, and the basic SERV server data communicate with the network via the respective programming interfaces APM, API2 and API3 as well as software layers which are interposed between each node and the RES network.

Each referenced component of this computer system exchanges messages. These messages can be transported via a protocol data unit PDU (Protocol Data Unit), known to those skilled in the art.

A user or client of the database queries the BDD database via the SERV server. The dialog that exists between a user and the BDD database is a client / server type dialog.

The application client and the application scent work with the database and carry out a series of transactions. Preferably, the tables are centralized on a node of the system. This centralization of the tables complies with the security criteria of a transaction. Access to the BDD database will be transactional to ensure data atomicity, consistency, isolation, and durability. By definition, atomicity means that a transaction must be completely carried out. Data consistency means that the transaction moves a system from one consistent state to another consistent state. Data isolation means that the transaction is not affected by the processing of other transactions. And finally, data durability means that changes due to a completed transaction are permanently guaranteed. Clearly, a given transaction either took place definitively or never existed.

Due to the centralization of the database relating to the tables, each node N1-N3 comprises a respective configuration file CFG1-

CFG3 which indicates the location of the associated BDD database including all the tables. These configuration files can be name scents, known to those skilled in the art. The choice of the node on which the database is arbitrary. According to another variant, there can be a single configuration file on any node.

FIG. 5 schematically illustrates an example of request for access to a privileged command. This figure represents the exchanges of messages between the different nodes of the computer system. This figure includes uni-directional arrows indicating the direction of execution of an action.

Prior to the access request,

H we create the database with the name of the first administrator having all the rights on the database,

this first user fills the database with the list of users having read and write rights on this database. Preferably, these users are limited to read rights in order to check the criteria mentioned above,

H each node N1-N3 is informed of the position of the database BDD in the computer system. This position is included in the configuration files CFG1-CFG3.

At this stage, a request for access to a privileged command by the user UT1 is possible and takes place as follows:

First, a write request is made by the user UT2 of a PRINTA command associated with an application of which he is the owner.

The database can include identical command names and identical application names. When a user launches an order, the administrator must associate, in the tables included in the database, this order with his respective application. For this purpose, the database gives the possibility to a user to write or read information in the database only if it has a unique application identifier in its possession.

Thus, secondly, the database issues, in return, a unique application identifier ID-PRINTA. In this way, commands and / or applications with identical semantics can coexist in the database.

Third, since the user has the unique application identifier, he can write to or read from the database. An example of writing to the database is given by the table shown in FIG. 6. This table is described in the following description. According to this example, the user UT1 of the node N1 is authorized to use the PrintA command remotely and remotely with the identity of the user UT2 belonging to the group GP2 of the node N2 between 12 noon and 1 pm.

Fourth, the database is updated to update.

Fifth, the user UT1 can launch a request for authorization to execute DDE of a privileged command belonging to a user present on any node of the network. In the example illustrated, User UT1 wishes to execute the PrintA command of which user UT2 is the owner. At this time, the SAP application server is responsible for consulting the BDD database. For this, it accesses the database with the name of the PrintA command accompanied by its unique identifier for ID-PrintA applications for the reasons mentioned above. The DDE request is made.

Sixth, the database associated with its SERV file server issues a result. This result can be of binary type "0" or "1" depending on the spatial or temporal constraints associated with a user.

For example, the “0” means that the user UT1 does not have the authorization to execute privileged commands. The result "1" means that the user is authorized to execute the privileged command. In the example illustrated, the user UT1 of the node N1 is authorized to use the PrintA command remotely and remotely with the identity of the user UT2 belonging to the group GP2 of the node N2 between 12 noon and 1 pm. If user UT1 respects the 12-13h calendar, the execution request is authorized. From then on, the command is executed.

Preferably, the network is perfectly secure via a programming interface of the GSS-API type (Generic Security Service - Application Program Interface). A GSS-API type programming interface provides security during a transaction between any node and the BDD database. This type of interface provides applications with the possibility of securing their exchanges by offering them mutual authentication, integrity and confidentiality. This programming interface can rely on various security mechanisms such as the DCE (Distributed Computing Environment) mechanism of the organization called OSF (Open Software Foundation), known to those skilled in the art. Preferably, the connection between an SAP application server and the BDD database is secured by means of such a programming interface. Access to the information that flows between the SAP application scent and the BDD database is impossible. A fraudster cannot therefore read or modify the information circulating between the SAP server and the database.

The position of the database BDD can be envisaged as a function of the distance which separates the nodes N1-N3. This BDD database can be replicated on a node and be used in reading and not in writing to comply with the criteria of a transaction. The database can be, for example, replicated on node N1. According to a variant, if the nodes NO and N1 are close to each other and the node N3 is distant from them, it may be advantageous to replicate the database in order to reduce the response time of the database . For reasons of properties transactional, this BDD database is used only for reading. During a replication of the database, it is necessary to modify the configuration files of the nodes concerned.

According to another variant, the tables include usage constraints other than the spatial type constraints as defined above. There may be other constraints in the database which aim to contribute to and improve the security of access to said privileged commands. Tables can include time constraints. These constraints are described in connection with FIG. 6 and are explained in the following description. These constraints are added to the spatial constraints of step 30 of FIG. 2a.

According to the example illustrated in FIG. 5, a table can materialize by means of a two-dimensional table. In this table, there are several columns:

- a first column, named "user", identifies the users whose administrator assigns all or part of the rights to at least one privileged order.

- a second column, called "rights", which defines the set of rights, defined above, that a user of the column. This second column includes sub-columns associated with these different rights:

- A first sub-column includes the name of the user UT2 who belongs to the GP2 group itself undue in the node N2, and who is the owner of the commands which the user UT1, present in the first column, wishes to use.

- a second sub-column includes the name of the application

APP2 owned by user UT2 and which user UT1 is authorized to use. - A third sub-column includes the name of the printA command associated with the APP2 application of which the user UT2 is the owner and that the user UT1 is authorized to use. The semantics given to an order are specific to an application thanks to the unique identifier for applications.

At least one other sub-column includes a time constraint. Such constraints may consist in authorizing access to a privileged order for a period of time defined by the administrator. In FIG. 6, a constraint is noted “calendar”. In the example illustrated, the application authorizes the user UT1 to use the command associated with the application APP whose owner is the user UT2 belonging to the owner group GP2 of the node N2 between 12 noon and 1 pm. If a request to use a privileged order is made outside of the calendar hours, it is refused and considered a fraudulent request.

The tables included in the database are not frozen but on the contrary are extensible. Other constraints can therefore be defined later depending on the needs of the applications. The meaning of the constraints depends on each application.

The administrator completes each row and each column of the table.

According to another variant, the ADM administrator intervenes in the allocation of execution rights for privileged orders. This administrator can assign or withdraw rights. The tree structure, defined above, is not, for this purpose, frozen in time, but can instead evolve over time. This evolution consists either of adding branches or deleting branches in the tree structure. In other words, this development corresponds to authorizing, or withdrawing at any time, access rights to privileged orders. The invention allows It is up to a user to directly activate commands and to dynamically acquire the authorization to execute privileged commands without hindering access authorization requests from other users. For example, user UT3 can launch a request including a request for authorization to execute privileged commands. During the processing of this request, the method consists in removing or granting rights to another user. In other words, the method offers the possibility of solving or avoiding the problems posed by the simultaneous access of several users.

According to another variant, the choice of a password PW of a user is the responsibility of the user holder of the password. Similarly, its renewal is the responsibility of the associated user. Regular renewal is strongly recommended because the longer the period of password use, the greater the risk of being known by third parties.

In general, it can be said that the subject of the invention is a method of accessing privileges for executing privileged commands in a SYS computer system, said system comprising at least one GP1- GP3 group owning privileged commands. , said group comprising at least one respective user UT1-UT3 having both a respective password PW1-PW3 for connection to the SYS system and a respective user identifier IU1-IU3 assigned by an administrator, said user issuing requests REQ including at least one order. The method consists, for a user UT1-UT3, of accessing a privileged command of another user via his own respective user identifier IU1-IU3.

In the algorithm of FIG. 2a, reflecting the different steps of the method of the invention, we have seen that the method is activated by the request REQ. Activation consists in verifying that the REQ request contains the information necessary to authorize a user U1-U3 to access a command privileged of another user. We have seen that the verification of the necessary information consists in verifying in privilege tables of execution of privileged commands granted, both if the user identifier IU1 - IU3 is authorized to use a privileged command and if the user is authorized to execute the privileged command resulting from the REQ request.

We have also seen in FIG. 2b, that the activation of the method consists in including a parameter PRC in the request REQ characteristic of a request for execution of privileged command. In an example, we have seen that this additional parameter can be a PRC prefix associated with the REQ request.

In another example, we have seen that an administrator can intervene in the system in the allocation of execution rights for privileged orders and that the method consists in granting and / or withdrawing the right to execute a privileged order. to a user UT1 -UT3 through an administrator. The method consists in dynamically acquiring, for a user UT1 -UT3, the right to execute a privileged command. According to this variant, the method consists in acquiring and / or withdrawing the right to execute a privileged command from a user without interfering with a request for execution of the right to execute a privileged command from another user.

We have also seen that the method consists in granting and executing the request or in rejecting it with a single error message so as to give no indication of the cause of the failure.

According to a variant aiming to contribute and improve the security of access to said privileged commands, it is preferable to include in the tables at least one time constraint. These tables are, for example, included in a BDD database. In this BDD database, the constraints have a semantics specific to each application and also have a meaning specific to each application. To comply with the security criteria of a transaction, it is preferable to manage the tables centrally on a single node.

We have seen that the subject of the invention is a computer system comprising at least one GP1-GP3 group which owns execution rights for at least one privileged command, said group comprising at least one respective user UT1-UT3, characterized in that that it includes a software mechanism for authorizing access to privileged commands implementing the method defined above. The software mechanism according to the invention comprises tables including the identifiers of the users IU1-IU3 authorized to execute privileged commands and the rights to execute corresponding privileged commands.

And finally, we have also seen that the present invention is applicable in a computer system which has a local or distributed type environment.

It appears from the examples illustrated that the invention offers numerous advantages. It allows a user to easily access privileged commands via their own user identifier. A user simply needs to know their own password for logging into the system. The "su-usemame" command no longer needs to exist. In the invention, a request for execution of privileged commands therefore no longer requires the integration of a password in the request. This characteristic complies with the confidentiality and security criteria. In addition, the invention offers the advantage of being selective in the allocation of privileges to execute privileged orders. Indeed, a request concerns only one and only order. In addition, using a file tree allows the mechanism to focus only on processing orders. The administrative part of granting or withdrawing rights to such or such user is easily carried out using a file manager like those proposed by WINDOWS (Trademark) or CDE (Common Desktop Environment) (Trademark). The deletion or addition of rights does not imply the modification of software components contained in the system. This deletion or the addition of rights does not imply either the modification of the associated password. The process is therefore simple to use. The invention also offers the advantage of allowing any computer application to manage in a personalized manner (the semantics granted to an order in the tables is specific to each application) and fine access to privileged orders. It also offers the advantage of homogeneity of use (use of API-type programming interfaces) and administration provided by centralizing information relating to these accesses.

Claims

R E V E N D I C A T I O N S

1 - Method for accessing privileges for executing privileged commands in a computer system (SYS), said system comprising at least one group (GP1-GP3) owner of privileged commands, said group comprising at least one respective user (UT1 -UT3) having both a respective password (PW1-PW3) for connection to the system (SYS) and a respective user identifier (IU1-IU3) assigned by an administrator (ADM), said user issuing a request (REQ) including at least one command, characterized in that it consists, for a user (UT1-UT3), of accessing a privileged command of another user via his own respective user identifier ( IU1-IU3).

2- A method according to claim 1, characterized in that it is activated by the request (REQ), the activation consisting in verifying that the request (REQ) contains the information necessary to authorize a user (U1-U3) to access to a privileged command from another user.

3- Method according to claim 1 or 2, characterized in that the verification of the necessary information consists in verifying in tables of execution rights of privileged commands granted, both if the user identifier (IU1-IU3) is authorized to use a privileged command and if the user is authorized to execute the privileged command resulting from the request (REQ),

4- Method according to one of claims 1 to 3, characterized in that the activation consists in including a parameter (PRC) to the request (REQ) characteristic of a request for execution of privileged command. 5- Method according to one of claims 1 to 4, characterized in that it consists in granting and / or withdrawing the right to execute a privileged command to a user (UT1 -UT3) via the '' administrator (ADM).

6- Method according to one of claims 1 to 5, characterized in that it consists in dynamically acquiring, for a user (UT1-UT3), the right to execute a privileged command.

7- Method according to one of claims 1 to 6, characterized in that it consists in acquiring and / or withdrawing the right to execute a privileged order to a user without interfering with a request for execution right d '' a privileged order from another user.

8- Method according to one of claims 1 to 7, characterized in that it consists in granting and executing the request or in rejecting the request with a single error message so as to give no indication of the cause of the failure.

9- Method according to one of claims 1 to 8, characterized in that it consists in including in the tables at least one time constraint.

10- Method according to one of claims 1 to 9, characterized in that it consists in adding constraints whose semantics is specific to each application and whose meaning is specific to each application.

11- Method according to one of the preceding claims, characterized in that it consists in managing the tables centrally on a single node.

12- computer system (SYS) comprising at least one group (GP1- GP3) owner of execution right of at least one privileged command, said group comprising at least one respective user (UT1-UT3), characterized in that it includes a software mechanism for authorizing access to privileged commands implementing the method defined by one of claims 1 to 11.

13- System according to claim 12, characterized in that the software mechanism comprises tables including the identifiers of the users (IU1-IU3) authorized to execute privileged commands and the rights of execution of corresponding privileged commands.

14- Computer system according to claim 12 or 13, characterized in that it has a local or distributed type environment.