Entrées d'ACL

Une ACL consiste en une série d'entrées jointes à un objet logiciel lors de sa création. Les entrées ACL définissent les utilisateurs, groupes et/ou hôtes disposant du droit d'accès aux objets. Les entrées d'ACL appliquent le concept d'initiateur, qui indique l'utilisateur, le groupe ou le système hôte (pour les agents qui émettent des appels RPC) qui est à l'origine d'un appel à un autre système.

Une entrée d'ACL comporte trois zones :

type_entrée[:clé]:droits

Par exemple, l'entrée d'ACL d'un objet SD-UX sera :

user:pierre:r-ctw

Elle signifie que l'utilisateur pierre peut contrôler (c), lire (r), écrire (w) et tester (t) l'objet. Le tiret indique qu'il ne peut i (insérer/créer) de nouveaux objets.




	REMARQUE : Il est possible de spécifier les droits `crwit` dans un ordre arbitraire.

La zone ACL type_entrée doit avoir l'une des valeurs suivantes :

Tableau 9-3 Types d'entrées ACL SD-UX

Type	Droits d'accès pour
`user`	Utilisateur initiateur, dont le nom doit être spécifié dans la zone `clé`
`group`	Groupe initiateur, dont le nom doit être spécifié dans la zone `clé`
`host`	Systèmes hôtes (agents cibles agissant pour le compte d'utilisateurs pour les commandes install ou copy)
`other`	Initiateurs n'ayant pas d'entrées « user » et « group » correspondantes
`any_other`	Initiateurs ne correspondant à aucune autre entrée
`object_owner`	Propriétaire de l'objet
`object_group`	Membres du groupe auquel appartient l'objet




	ASTUCE : Ne confondez pas l'objet hôte (qui est un système informatique contenant des dépôts, des répertoires racine et des logiciels) avec le type d'entrée `host` (qui définit les autorisations d'accès aux systèmes cibles).

L’utilisateur (user) et le groupe (group) du propriétaire de l’objet sont déterminés et automatiquement consignés lors de la création de l’objet, en fonction de l’identité de la personne qui le crée. Ces informations sont consignées sous user, group et realm. Une entrée de type object_owner ou object_group dans une ACL fait en sorte que le gestionnaire d'ACL vérifie les informations de propriétaire et de groupe de l'objet, et, si ces dernières concordent avec celles du demandeur, il accorde les droits d'accès spécifiés.

Chaque ACL peut contenir de nombreuses entrées user, group et host, tandis qu'une seule entrée est permise pour object_owner, object_group et any_other. Il ne peut y avoir qu'une seule entrée other locale (donc sans clé), mais il peut y avoir un nombre illimité d'entrées other « à distance » (avec clé).

Clés d'ACL

La deuxième partie d'une entrée ACL est appelée clé. Le tableau suivant donne la liste des valeurs que peut prendre la clé pour des types d'entrées spécifiques.

Tableau 9-4 Valeurs de la clé des entrées d'ACL SD-UX

Type d'entrée	Contenu de la clé
`user`	un nom d'utilisateur [facultativement, @ `hôte-distant`]
`group`	un nom de groupe [facultativement, @ `hôte-distant`]
`host`	un nom d'hôte
`other`	[facultativement, @ `hôte-distant`]
`any_other`	aucune clé permise

Lorsque vous listez l'ACL, l'hôte est désigné par son adresse Internet (par exemple, 15.12.89.10) si le système local n'arrive pas à interpréter l'adresse à partir de son mécanisme de recherche sur l'hôte (DNS, NIS ou /etc/hosts). Il est nécessaire de reconnaître le système hôte-distant (résolution) lorsqu'il est utilisé dans les options -M et -D. Les valeurs de systèmes hôte-distant non reconnus sont acceptées dans les fichiers prévoyant l'option -F.

Droits d'accès des ACL

L'ACL permet de déterminer cinq autorisations différentes : crwit.

Tableau 9-5 Droits d'accès des ACL

control (`c`)	Autorisation de modifier l'ACL.
test (`t`)	Droit de tester l'accès à un objet (c'est-à-dire, lire l'ACL).
insert (`i`)	Autorisation d'installer un nouveau produit, dépôt ou répertoire racine.
write (`w`)	Autorisation de modifier un hôte, un dépôt, un répertoire racine ou un produit.
read (`r`)	Autorisation de lister des dépôts, des répertoires racines, des produits et des attributs.

Dans l'entrée ACL, ces droits d'accès sont précisés sous forme abrégée c, t, i, w et r. Si vous accordez l'ensemble des droits, vous pouvez utiliser la lettre abrégée a à la place de l'option crwit pour indiquer l'ensemble des droits.

Les droits d'accès ont une signification différente pour les divers types d'objets, et ne doivent pas nécessairement apparaître dans un ordre précis. Les répertoires racines n'offrent pas de protection au niveau des produits. C'est pourquoi, tous les droits d'accès pour les produits installés dans ces répertoires sont régis par l'ACL protégeant le répertoire racine lui-même.

La protection au niveau des produits est offerte dans les dépôts de la manière suivante : l’ACL du dépôt protège le dépôt lui-même, tandis que les ACL des produits protègent les produits contenus dans le dépôt.

Le tableau suivant donne un résumé des droits d'accès aux objets SD-UX et des ACL auxquelles ils peuvent être appliqués.

Tableau 9-6 Définitions des droits d'accès aux ACL SD-UX

Droit d'accès	Autorisations accordées
	Système hôte	Répertoire racine	Dépôt	Produit en dépôt
`c` (control)	Éditer les ACL
`t` (test)	Tester l'accès à un objet, lire le contenu de l'ACL (liste)
`i` (insert)	Insérer un nouveau dépôt ou répertoire racine	Insérer un nouveau produit	Insérer un nouveau produit	S/O
`w` (write) ^[1]	Modifier l'hôte	Modifier le répertoire racine ou des produits	Modifier un dépôt	Modifier un produit
`r` (read) ^[2]	Lister les dépôts et les répertoires racines	Lister les attributs de répertoire racine et de produit	Lister les attributs de dépôt et de produit	Lire les fichiers de produits
^[1]L'autorisation d'écriture permet de modifier ou de supprimer l'objet, à l'exception de l'objet source hôte qui ne peut être supprimé. ^[2]L'autorisation de lecture sur les conteneurs (hôtes, répertoires racines et dépôts) permet d'en lister le contenu ; dans le cas des produits présents dans les dépôts, l'autorisation en lecture permet à un utilisateur de copier ou d'installer le produit.

Protection des objets

Le contrôle des autorisations d'insertion et de suppression de produit diffère pour les racines et les dépôts.

L’autorisation d’un utilisateur d’insérer ou de supprimer un produit dans un répertoire racine est spécifiée dans l’ACL de ce répertoire. Si vous avez l'autorisation d'écriture dans un répertoire racine, vous pouvez alors modifier ou supprimer n'importe quel produit contenu dans celui-ci ; les répertoires racines ne sont soumis à AUCUN contrôle au niveau des produits.

L'ACL d'un dépôt contrôle l'insertion (la création) de nouveaux produits, tandis que l'objet inséré possède sa propre ACL qui contrôle la modification et la suppression. Cette fonction permet au créateur (le propriétaire) d’un produit dans un dépôt de modifier, ou même de supprimer, le produit sans qu’il ait besoin de l’autorisation d’écriture plus globale susceptible d’avoir un effet sur les produits d’autres utilisateurs dans le même dépôt.

Cette fonction est utile pour contrôler les produits, car elle vous permet d'attribuer le contrôle de la gestion d'un produit spécifique à un administrateur mandaté. En outre, lorsqu'un produit est créé dans un dépôt, l'identification de l'utilisateur et celle de son groupe sont consignées dans les informations sur le produit.

Si l'ACL du produit contient une entrée object_owner accordant l'autorisation d'écriture au propriétaire, le créateur du produit a automatiquement le droit de le modifier ou de le supprimer. Par conséquent, il est plus facile d'insérer des produits dans le dépôt, puisque les utilisateurs ayant l'autorisation d'insertion peuvent uniquement y copier de nouveaux produits ou supprimer ceux qu'ils ont eux-mêmes créés : vous n’avez donc pas à craindre qu’un utilisateur supprime accidentellement (ou intentionnellement) un produit important qu’il n’a pas droit de contrôler.

Ce principe de protection a été emprunté à un mécanisme introduit dans les systèmes de fichiers BSD. Si vous disposez des droits d'écriture dans un répertoire BSD, vous pouvez y créer un fichier. Si le bit de mode résident est défini sur ce répertoire, seuls le propriétaire du fichier, le propriétaire du répertoire et le superutilisateur ont le droit de supprimer ou de renommer le fichier.

Par exemple : Dans le répertoire /tmp, appartenant à root, pour lequel l'autorisation d'écriture a été accordée à tous les utilisateurs et dont le bit de mode résident a été défini (mode 1777), n'importe quel utilisateur peut créer des fichiers que personne d'autre (à l'exception de lui-même et du superutilisateur) ne pourra supprimer. Cela fait de /tmp un emplacement plus sûr pour le stockage de travaux temporaires, car personne ne peut effacer vos fichiers à cet emplacement.

Pour installer ou copier des fichiers à partir d’un dépôt non enregistré, l’utilisateur et le système hôte de l’agent cible doivent disposer de l’autorisation d’insertion sur l’hôte du dépôt. Si cette autorisation vous est refusée, le fichier de consignation produit par le démon du dépôt contiendra le message suivant :


ERROR: Accès interdit à Agent SD sur le système hôte lucille pour le 
compte de martin@lucille pour lancement de l’agent sur le dépôt 
désenregistré "/users/martin/depot." Aucune autorisation (i)nsert sur 
lucille.
  07/23/01 15:51:06 MDT

Ce message précise que c’est l’AGENT sur l’hôte lucille qui n’avait pas l’autorisation d’insertion sur l’hôte du dépôt, et non l’utilisateur martin@lucille.

L'ACL de l'hôte à distance doit contenir deux entrées accordant l'autorisation d'insertion : une pour l'utilisateur et l'autre pour l'hôte cible.

Par exemple, pour que l'utilisateur martin puisse installer un produit sur son hôte cible lucille à partir d'un dépôt non enregistré (UNREGISTERED) sur l'hôte source desi, la commande

swacl -l host @ desi

doit afficher au minimum les entrées ACL ci-après :

user:martin@lucille:-i-
 host:lucille:-i-

L'utilisateur « martin » peut également enregistrer le dépôt au moyen de la commande swreg avec seulement la première entrée ci-dessus, avant d'exécuter swinstall ou swcopy.

ACL de système hôte

Avec SD-UX, le système hôte constitue le niveau le plus élevé d'objet protégé. Une ACL hôte protège chaque système hôte en contrôlant les autorisations de création de dépôts et de racines. L'ACL hôte est en mesure de conférer les autorisations suivantes :

Tableau 9-7 Droits d'accès ACL de système hôte

`r (`read)	Autorisation d'obtenir les attributs de l'hôte, incluant la liste des dépôts et des répertoires racines qu'il contient.
`w (`write)	Autorisation de modifier l'objet hôte.
`i` (insert)	Autorisation de créer et d'enregistrer un nouveau dépôt ou répertoire racine sur l'hôte.
`c` (control)	Autorisation de modifier l'ACL.
`t` (test)	Autorisation de tester l'accès à un objet et de lister l'ACL.

Voici un exemple d'une ACL de système hôte accordant l'autorisation de création d'un dépôt et d'un répertoire racine, l'autorisation de liste du répertoire source et l'autorisation d'administration de l'ACL à l'utilisateur martin ainsi que l'autorisation de lister les dépôts et les répertoires racines sur l'hôte :

user:martin:r-ic-
any_other:r

Étant donné que les utilisateurs any_other n'ont pas l'autorisation de (t) est, seul martin peut lister l'ACL puisqu'il a l'autorisation c (contrôle).

ACL de répertoire racine

Les initiateurs (utilisateurs) identifiés dans les ACL protégeant les répertoires racines ont l'autorisation de gérer les produits installés. Les droits d'accès associés à un répertoire racine sont les suivants :

Tableau 9-8 Droits d'accès associés à un répertoire racine

`i` (insert)	Autorisation d'installer un nouveau produit.
`r (`read)	Autorisation de lister le contenu du répertoire racine.
`w (`write)	Autorisation de supprimer le répertoire racine lui-même ou les produits qu'il contient.
`c` (control)	Autorisation de modifier l'ACL.
`t` (test)	Autorisation de tester l'accès à un objet et de lister l'ACL.

Voici un exemple d'ACL de répertoire racine accordant à l'utilisateur marie l'autorisation de lecture, d'écriture et d'insertion de logiciels, et accordant aux membres du groupe swadm tous les droits d'accès possibles :

user:marie:rwi-
group:swadm:crwit

Lorsqu'un répertoire racine est créé, il est automatiquement protégé par une ACL par défaut provenant de son hôte. Vous pouvez utiliser swacl pour modifier les valeurs initiales de cette ACL. Pour de plus amples informations, voir « Modèles d'ACL ».

ACL de dépôt

Les initiateurs identifiés dans les ACL protégeant les dépôts sont des utilisateurs qui ont reçu l'autorisation de gérer les dépôts et de créer de nouveaux produits. Les droits d'accès associés à un dépôt sont les suivants :

Tableau 9-9 Droits d'accès associés à un dépôt

`i` (insert)	Autorisation de copier un nouveau produit dans le dépôt.
`r (read)`	Autorisation de lister le contenu (produits) du dépôt source.
`w (write)`	Autorisation de supprimer le dépôt (s'il est vide) et d'annuler son enregistrement (et non les produits qu'il contient).
`c (control)`	Autorisation de modifier l'ACL.
`t (test)`	Autorisation de tester l'accès à un objet et de lister l'ACL.

Voici un exemple d'ACL de dépôt servant à accorder l'ensemble des droits à son créateur ; le droit de l'utilisateur george à répertorier et insérer des produits logiciels ; les droits des membres du groupe swadm à répertorier et insérer des produits, à modifier l'ACL et supprimer le dépôt lui-même ; et le droit pour tout autre utilisateur à répertorier le dépôt :

object_owner:crwit
user:george:-r-i-
group:swadm:crwi-
any_other:-r-

Lorsqu'un objet de dépôt source est créé, il est automatiquement protégé par une ACL par défaut provenant de son hôte. Les produits insérés dans ce dépôt sont à leur tour automatiquement protégés par l'ACL provenant du dépôt. Ce concept est présenté à la section « Modèles d'ACL ».

ACL de produit

Les ACL de produit s'appliquent uniquement aux produits contenus dans les dépôts. Les produits se trouvant dans les répertoires racines sont protégés par les ACL de ces répertoires. Il y a deux classes d'initiateurs ayant des droits d'accès aux produits :

Tableau 9-10 Initiateurs de produits

utilisateurs	Obtiennent diverses autorisations administratives. Cette classe inclut les utilisateurs de type « group » et « other », à la fois sur l'hôte local et à distance.
hôtes	Les systèmes cible (agent/démons) obtiennent l'autorisation de lecture aux fins d'installation de produits.

Les droits d'accès aux produits sont les suivants :

Tableau 9-11 Droits d'accès aux produits

`w (`write)	Autorisation aux utilisateurs de modifier et de supprimer le produit et/ou les informations sur celui-ci.
`r (`read)	Autorisation accordée aux hôtes cibles de lire le produit du dépôt source (en d'autres termes, autorisation à un système à distance d'installer le produit protégé).
`c` (control)	Autorisation de modifier l'ACL.
`t` (test)	Autorisation de tester l'accès à un objet.

Voici un exemple d'ACL de produit accordant à l'utilisateur swadm et au créateur du produit tous les droits d'accès possibles, et accordant l'autorisation de lecture à tous (distribution libre à tous les systèmes) :

user:swadm:crw
object_owner:crw
any_other:-r-




	REMARQUE : Encore une fois, lorsqu'un produit est créé, il est automatiquement protégé par une ACL par défaut provenant du dépôt source ou du répertoire racine source, ou encore, en l'absence de celles-ci, de l'ACL de l'hôte.

Modèles d'ACL

Il existe deux ACL pour créer les ACL d'origine destinées à protéger les objets nouvellement créés : modèles d'ACL de produit (global_product_template ou product_template) et modèles d'ACL de conteneurs (global_soc_template).

Figure 9-2 Modèles d'ACL

Lorsqu’un produit est installé dans un dépôt au moyen de swcopy ou de swpackage, SD-UX utilise un modèle d’ACL de produit (fourni par le dépôt contenant ce produit) afin de définir les droits d’accès initiaux de l’ACL du nouveau produit.

SD-UX utilise le modèle d'ACL de produit du système hôte (global_product_template) pour initialiser le modèle d'ACL de produit du nouveau dépôt, et utilise le modèle d'ACL de conteneur du système hôte (global_soc_template) pour initialiser les ACL du dépôt et du répertoire racine.

Par conséquent, l'hôte compte trois ACL :

ACL d'hôte
Jointe à l'objet hôte lui-même et contrôlant l'accès à celui-ci.
Modèle(s) d'ACL de conteneur (global_soc_template)
Utilisé pour initialiser l'ACL protégeant les nouveaux dépôts et répertoires racines créés sur l'hôte.
Modèles d'ACL de produit (global_product_template)
Utilisé pour initialiser le modèle d'ACL de produit dans les dépôts créés sur l'hôte.

Les dépôts de produits comptent en outre deux ACL :

L’ACL de dépôt utilisée pour déterminer les droits d’accès à celui-ci.
Le modèle d’ACL de produit du dépôt (product_template) utilisé pour initialiser les ACL protégeant les nouveaux produits dans le dépôt.

Le répertoire racine, pour sa part, compte une ACL :

L'ACL de répertoire racine protégeant le répertoire lui-même et les produits qui y sont installés.

Enfin, le produit compte une ACL :

L’ACL de produit utilisée pour déterminer les droits d’accès à celui-ci.

Chaque hôte doit avoir une ACL le protégeant, ainsi que deux modèles d'ACL (produit et conteneur) fournissant les données d'initialisation pour les ACL implicites des dépôts et des produits. Ces trois ACL sont créées lors de l'installation de SD-UX sur l'hôte.

Entrées de modèle d'ACL par défaut

Le modèle d’ACL de conteneur du système hôte dicte les droits d’accès initiaux pour tous les dépôts et répertoires racines créés sur cet hôte. L'hôte contient également une copie maîtresse du modèle d'ACL de produit, qui est copiée dans chacun des nouveaux dépôts.

Un ensemble par défaut d'ACL d'hôte est fourni au moment de l'installation de HP-UX, que l'administrateur du système peut modifier. Le contenu de ces ACL de système hôte se présente comme suit immédiatement après l'installation SD-UX :

ACL d'hôte

L'ACL d'hôte ci-dessous donne des droits globaux (any_other) permettant d'établir la liste des dépôts et des répertoires racine du système hôte :
object_owner:swadm:crwit any_other:-r---




	REMARQUE : Le superutilisateur local a toujours tous les droits d'accès possibles, même sans entrée ACL.

Modèle d'ACL de conteneur

Le modèle d'ACL de conteneur ci-après accorde au propriétaire ou au créateur (object_owner) d'un nouveau dépôt ou répertoire racine l'autorisation de gérer ce dépôt ou ce répertoire ainsi que de modifier son ACL. Elle accorde également l'autorisation globale (any_other) de lister des produits contenus dans le nouveau dépôt ou répertoire racine.
object_owner:crwit any_other:-r---

Modèle d'ACL de produit

Le modèle d'ACL de produit ci-après accorde l'autorisation d'exécuter toutes les opérations possibles sur les produits installés dans les dépôts de cet hôte au créateur respectif (owner) de chaque produit, par l'intermédiaire de l'entrée object_owner. Elle accorde également à “n'importe quel hôte” (entrée any_other ) l'autorisation de lire (installer) et de tester le produit.
object_owner:crwit any_other:-r---
En plus d’inclure tous les hôtes, l’entrée any_other s’applique aussi à tous les autres utilisateurs à l’exception, dans ce cas, du propriétaire du produit. Cependant, l'autorisation de lecture sur un produit n'a une signification que pour les hôtes-initiateurs, et toute autre autorisation sur les produits ne s'applique jamais aux hôtes. Par conséquent, vous pouvez si vous le désirez surcharger l'entrée any_other d'autorisations pour les utilisateurs et les hôtes, sans aucun risque d'ambiguïté. Gardez à l'esprit cette surcharge lorsque vous utilisez des commandes SD-UX.

Ces ACL d'hôte par défaut fournissent un bon point de départ pour le contrôle des fonctions de gestion, tout en offrant l'autorisation de lecture à tous les utilisateurs sur les logiciels pour l'installation dans des répertoires racines cibles.