RPCSEC_GSS utilise certains fichiers pour stocker des informations.
Lorsqu'un serveur extrait les justificatifs d'identité de client associés à une requête, il peut obtenir soit le nom de principal du client (sous forme d'un pointeur de structure rpc_gss_principal_t), soit les justificatifs d'identité UNIX locaux (UID) de ce client. Des services tels que NFS exigent un justificatif d'identité UNIX local pour la vérification d'accès, mais d'autres non ; ils peuvent, par exemple, enregistrer le nom de principal, en tant que structure rpc_gss_principal_t, directement dans leurs propres listes de contrôle d'accès.
La correspondance entre le justificatif d'identité réseau d'un client (son nom de principal) et tout justificatif d'identité UNIX local n'est pas automatique -- elle doit être explicitement définie par l'administrateur de sécurité local.
Le fichier gsscred contient les justificatifs d'identité UNIX et réseau du client (par exemple, Kerberos V5). (Ce dernier est la représentation hexadécimale-ASCII de la structure rpc_gss_principal_t.) On y accède via XFN ; par conséquent, cette table peut être mise en oeuvre pour des fichiers, NIS ou NIS+, ou tout autre service de nom ultérieur pris en charge par XFN. Dans la hiérarchie XFN, cette table est identifiée comme this_org_unit/service /gsscred. La table gsscred est maintenue au moyen de l'utilitaire gsscred, qui permet aux administrateurs d'ajouter et de supprimer des utilisateurs et des mécanismes.
Pour fins de commodité, RPCSEC_GSS utilise des constantes de chaîne pour représenter des mécanismes et des paramètres de qualité de protection. Toutefois, les mécanismes sous-jacents exigent eux-mêmes que les mécanismes soient représentés en tant qu'identificateurs d'objets, et les qualités de protection sous forme de nombres entiers à 32-bits. En outre, pour chaque mécanisme, la bibliothèque partagée mettant en oeuvre les services pour ce mécanisme doit être spécifiée.
Le fichier /etc/gss/mech enregistre les informations suivantes sur tous les mécanismes installés sur un système : le nom du mécanisme, en format ASCII ; l'OID du mécanisme ; la bibliothèque partagée mettant en oeuvre les services fournis par ce mécanisme ; et, facultativement, le module de noyau mettant le service en oeuvre. Voici un exemple de ligne :
kerberos_v5 1.2.840.113554.1.2.2 gl/mech_krb5.so gl_kmech_krb5 |
Le fichier /etc/gss/qop enregistre, pour tous les mécanismes installés, toutes les qualités de protection prises en charge par chaque mécanisme, sous forme de chaîne ASCII et du nombre entier à 32-bits correspondant.
Les fichiers /etc/gss/mech et /etc/gss/qop sont créés lors de l'installation initiale des mécanismes de sécurité sur un système particulier.
Puisque plusieurs des sous-programmes RPC intégrés au noyau emploient des valeurs autres que des chaînes pour représenter le mécanisme et la qualité de protection, les applications peuvent utiliser les fonctions rpc_gss_mech_to_oid() et rpc_gss_qop_to_num() pour obtenir les équivalents de ces paramètres en format autre qu'une chaîne afin de tirer parti de ces sous-programmes.