Security issue

Some plugins manage the generation of the configuration for services with high security considerations (DNS, DHCP, ...). However, these informations are generated from the database of GLPI. So, whatever user of these objects, he must have the agreement to do that. These rights may be given by the administrators of the local entity.
However, most of these informations do not rely on entity tree because everybody (all around the world) share the same ressources. For instance IP addresses even exceed "GLPI world" (ie : network addresses ranges are provided by RIPE, ARIN, ...).
So, we must introduce a strong agreement procedure to allow people to enter theses informations.

Delegation

I suggest the use of specific right management by the notion of delegation : there is two kind levels of rights. The first level is owned by the "big administrators" of the system (ie : the guys who are "super-admin" recursively on root entity). The second level of right is a "delegation" of control (a kind of warrants). This delegation has been given by a guy who have rights to do such. For instance, this user should be the owner of the ressource. This owner can do whatever he wants for this ressource (keep it "as is" of cut and delegate it). But he cannot extend it over its boundaries, as this ownership may be given by the delegation of something bigger.
The key difference between owner and warrants is that a warrants can change the "delegation" state of a ressource.

Implementation

Form of the implementation

We have seen (by exchange on the mail list of GLPI developpers) that several methods are possible to implement this feature.
So, I suggest the development of a plugin. Thus, by default GLPI won't bored the administrators of GLPI by this feature.

Plugin

The implementation of the plugin is quite simple : it rely on two fields associated with each resource. These fields are :
  • the owner of the resource ;
  • the delegation state of the resource.

With theses two fields, the table also contains the type name of the resource and its ID. Thus, each time an element is created, a new entry is done inside the plugin database table. Same thing when a resource is deleted : the entry in the plugin database table is droped.
Moreover, to finely control the resource, a tab is added to control the owner and the delegation state of a resource.
To be able to modifiate the boundaries of a supervised element (internet domain, IPv4 network, ...), the supervisor will check if the user has ownership of its direct father. The same check is done when the user try to create or to deleted an item. If the user try to modify an element of the resource (for instance, the gateway or the "automatic" field), the supervisor just look for the delegation state of the item.