Bonjour,
Je pensais n'introduire qu'un seul type de droit : "internet_manager"
(peut être à renommer "internet", mais nous verrons cela plus tard).
Ce dernier contrôle l'accès à tout ce qui concerne internet (en
l'occurence, adresses IP et domaines internet).
Droits associés et leurs signification :
* haveRight("internet_manager", "w") => possibilité de création,
modification et destruction des réseaux et des domaines internet. Je
montrerais, plus bas comment je proposes de gérer le cas particulier
posé hier matin.
* haveRight("internet_manager", "r") => possibilité de création
d'adresse IP au sein de ces réseaux (sous entendu : on a le droit de
voir les réseaux, donc, on peut y mettre une machine).
* Le champs "is_recursive" servirait uniquement dans le cas de la
lecture. En effet, un réseau peut être délégable, sans pour autant
autoriser les gens à y créer des machines. Par exemple, lorsque l'on
attribue (délégation) un réseau à un administrateur, d'un côté, il
pourra le redécouper en sous réseau (auquel cas, il interdira à
quiconque de créer des adresses hors de ces sous-réseau). D'un autre
côté, un réseau peut être délégué, mais autoriser toutes les entitées en
dessous à créer des addresses dedans (exemple de l'entitée redécoupée en
"gestion", "administration", "enseignement", ...).
Dans mon analyse, je suis arrivé à la conclusion qu'un sous-réseau ne
peut être créé que si le réseau "visible" (ie : appartenant à la même
arborescence des entitées que l'entitée courante) juste au dessus (à
vérifier avec les adresses du réseau et les masques) est délégable, ou
si nous sommes "propriétaire" de ce dernier.
D'une part, seul le réseau au dessus compte (ie : pas de récursion dans
les réseaux). En effet, cela permet de limiter la délégation dans la
hiérarchie. Par exemple, une entitée peut déléguer un réseau à une
sous-entitée. Mais cette dernière peut ne pas vouloir transmettre ce
droit à ses sous-sous-entitées. Pour cela, elle recréera des sous-réseau
sans droit de délégation qui masqueront la délégation du réseau "père".
D'autre part, j'introduis, ici, la notion d'entitée "propriétaire"
(nouveau champs), différente de l'entitée "de localisation" (champs
classiquement nommé "entities_id"). Par analogie avec Unix, nous
pourrions assimiler le champs "entities_id" au groupe (gid), alors que
le champs "propriétaire" à l'utilisateur (uid). Toujours selon cette
analogie, le"propriétaire" a le droit de modifier tous les attributs (le
contenu et le contenant), alors que le "groupe" n'a le droit que de
modifier le contenu (les informations propres commune l'objet). Dernière
référence à l'analogie : le "chmod" n'est accessible que pour le
propriétaire d'un noeud.
Je mets l'adresse de réseau, le netmask et le champs "délégable" dans le
contenant. Alors que les autres informations liées au réseau
(possibilité d'attribution d'adresse IP automatiquement, adresse de la
passerelle, adresse des serveur DNS, ...) font partie du contenant
(donc, modifiable par l'entitée délégataire). Le fait de considérer les
champs "subnet", "netmask" et "délégable" comme contenant évite que
l'entitée qui ne possède pas ce réseau altère ses caractéristique et
induise une faille dans le plan d'adressage dont elle n'est pas auteur
(pour mémoire, l'auteur du plan d'adressage en question est celui qui a
créer ce réseau, donc, son propriétaire).
De même, les attributs du contenant (ie : "subnet", "netmask",
"délégable") ne peuvent être modifier que si nous sommes propriétaire du
réseau en question. Si nous avons le droit "internet_manager" en
écriture, nous pouvons modifier tous les autres champs.
Retour sur le cas présenté hier :
Étant donné deux entitées "supérieur" et "inférieur", avec "supérieur"
est l'entitée contenant "inférieur". Si j'ai bien compris, "supérieur"
va créer des réseaux pour "inférieur". "Inférieur" n'aura le droit de
créer des sous-réseau que pour certains de ces sous-réseau. Au
demeurant, il n'a pas le droit de modifier les réseaux qui lui ont été
attribués. Dans ce cas, les réseaux créer par "supérieur" sont la
"propriété" de "supérieur", mais "inférieur" peut les voire. De plus, il
peut créer des sous-réseau pour ceux qui sont marqués "délégable". En
revanche, "inférieur" ne peut modifier le fait que tel ou tel réseau qui
ne lui appartient pas est délégable ou pas. En revanche, elle peut
modifier tous les réseaux qu'elle a créé (à moins que "supérieur" ne lui
retire ce droit en s'appropriant les réseaux en question).
Dans la proposition de Julien, j'ai du mal à comprendre qui a le droit
de modifier l'attribut "délégable" d'un réseau.
Est-ce l'admin global de l'entitée (ie :
haveRight("global_internet_manager","w") == true) ? Si oui, alors si une
entitée a délégation sur un réseau (ie :
(haveRight("global_internet_manager","w") == false) &&
(haveRight("delegate_internet_manager","w") == true)) et qu'elle créée
un sous-réseau, elle ne pourra pas à son tour déléguer ce dernier, car
elle n'aura pas les droits "global_internet_manager".
J'espère avoir été claire. Si vous le souhaitez, je peux réaliser un
shéma explicatif. Je le mettrai dans le wiki (est-ce possible d'y
inclure des "images" ?) lorsque j'y intègrerai cette proposition. Par
ailleurs, si ce que je proposes est validé, je me chargerais de rédiger,
en Français et en Anglais, cette partie de la documentation de GLPI (en
plus de développer cette partie).
Cordialement
Damien
On 07/29/11 20:01, MoYo wrote:
Salut,
je ne saisi pas tout.
Tu n'indiques qu'un droit : internet_manager ca correspond à quel
droit : le droit global ou celui de la délégation ?
Par défaut pour moi ownerEntities = l'entité du réseau.
Je vais essayer de poser complètement ma vision de ce matin :
2 droits :
- global_internet_manager : administrateur global des réseaux : peut
tout faire
- delegate_internet_manager : administrateur délégué : ne peut créer
que des sous-réseaux
Et le check serait uniquement : canUpdate
haveAccessToEntity($A->getEntityID()) // Accès à l'entité
&& (haveRight("global_internet_manager","w")) // je suis admin global
de l'entité
|| (haveRight("delegate_internet_manager","w") &&
$A->isUnderDelegateAuthorizedNetwork()) // Le réseau est sous un
réseau délégué et j'ai le droit de délégation
)
r
Avec isUnderDelegateAuthorizedNetwork() qui va checker sur la suite
des parents getAncestors('glpi_networks') qu'il existe un réseau
délégué dans les entités du profile actif (pas les entités actives
attention). La gestion sur le profile complet permet la
sous-délégation. Exemple :
// Récupération des entités du profil actif : Il y aurait moyen de
factoriser avec la changeEntities
$entities = array();
foreach ($_SESSION['glpiactiveprofile']['entities'] as $key => $val) {
$entities[$val['id']] = $val['id'];
if ($val['is_recursive']) {
$sons= getSonsOf("glpi_entities", $val['id']);
if (count($sons)) {
foreach ($sonsas $key2 => $val2) {
$entities[$key2] = $key2;
}
}
}
}
// récupération des ancêtres du réseau courant
$ancestors = getAncestors('glpi_networks', $A->getID());
// Check si un des ancêtres
if (count($ancestors)) {
$network= new Network();
foreach ($ancestors as $networks_id) {
if ($network->getFromDB($networks_id)) {
if ($network->getField('delegate') == 1 &&
in_array($network->getEntitiesID(), $entities) {
return true;
}
}
}
}
// Retour false si aucun trouvé
return false;
Voilà c'est lourd comme checks mais nécessaires.
J'espère que d'avoir écrit les choses rend plus clair ce que je
voulais dire ce matin.
++
Julien
Le 29/07/2011 19:20, Damien Touraine a écrit :
Bonjour,
Suite à ce la réunion de ce matin, je me suis rendu compte qu'il
manquait quelque chose en plus du champs "delegation". En effet, il
faut que nous soyons capable de savoir qui a le droit de changer ce
champs ainsi que les bornes du réseau. En effet, ce ne peut être les
"internet_manager" (proposition de nom pour le module lié au
"haveRight") de l'entitée du réseau, car, sinon, ils pourraient
changer leur propre droit. Je pensais que nous pourrions nous en
sortir en restreignant sur la base des profiles, mais, j'ai peur que
cette information ne soit pas "générique" pour l'entitée et ne
dépende du réseau.
Je propose d'ajouter un champs supplémentaire "ownerEntities" qui
contiendrait l'identifiant de l'entitée qui a le droit de changer ce
paramêtre, ainsi que les bornes du réseau. Ce serait, en quelque
sorte le champs contenant le "déléguant". La valeur par défaut serait
l'entitée la plus élevée du profile en cours. Bien évidemment, lors
de la modification du réseau en question, les membres de
"ownerEntities" auront le droit de modifier ce paramètre.
Pour résumer ce que je proposes :
Nous pouvons modifier (Tout changer, y compris ses bornes et le
champs ownerEntities) le réseau A si (méthode canUpdateBoundaries):
haveRight("internet_manager","w") &&
haveAccessToEntity($A->getField("ownerEntities"))
Nous pouvons créer un sous réseau de A si :
$A->canUpdateBoundaries() || (
haveRight("internet_manager","w") &&
haveAccessToEntity($A->getEntityID()) && ($A->getField("delegation")
= 1)
)
Nous pouvons créer une adresse IP dans A si :
haveRight("internet_manager","r") &&
haveAccessToEntity($A->getEntityID())
Si nous souhaitons être encore plus générique nous pourrions définir
non pas une entitée propriétaire, mais plusieurs. Ma question est
donc : existe-t'il une "dropdown" permettant de choisir plusieurs
valeurs ? Par ailleurs, pourquoi ne pas utiliser un champs similaire
pour les entités déléguées à la création de sous réseau. Nous
pourrions, ainsi, avoir un droit plus fin que le droit récursif.
Bien évidemment, les tests ci-dessus seraient adaptés en conséquences.
Cordialement
Damien Touraine
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
--
--------------------------------------------------------------------
Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS
Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/)
Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64
--------------------------------------------------------------------
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
