1 votes

Accès au serveur NFS Kerberisé à partir de démons situés sur des serveurs clients spécifiques

J'ai une arborescence NFS exportée depuis un serveur de fichiers qui est sécurisé par Kerberos et utilise LDAP pour l'authentification et la gestion des uid/gid. Tout fonctionne parfaitement pour chaque machine cliente et chaque utilisateur individuel, mais je ne sais pas comment accorder l'accès à certaines parties du partage aux démons.

Les démons s'exécutent généralement avec un setuid sur un compte système local, il n'y a donc pas d'informations d'identification spécifiques pour eux sur le serveur. Si je peux m'introduire dans les sources et les modifier, je peux généralement les faire appeler kinit avec un fichier keytab pour un utilisateur qui existe dans kerberos lorsqu'ils démarrent, mais ce n'est pas toujours possible.

Notre environnement m'interdit d'ouvrir les choses en les rendant lisibles par tous, ou de supprimer complètement Kerberos du NFS.

J'ai bricolé en ajoutant un sous-arbre à /etc/exports con all_squash , anonuid=... y anongid=... mais cela ne fait que le rendre lisible par toutes les machines clientes. Il doit être accessible uniquement à une certaine machine.

J'ai essayé d'utiliser samba, mais nous avons certains démons qui ont une approche "NFS or bust" pour travailler avec les partages (tout ce qui implique mercurial, par exemple).

La plupart de nos serveurs fonctionnent sous Ubuntu 10.04 LTS, mais le problème affecte également un client 12.04 LTS que nous avons.

Existe-t-il un moyen d'accorder à un système entier un ticket pour un utilisateur Kerberos particulier, de sorte que tout utilisateur de ce système puisse toujours accéder au partage ? Ou existe-t-il une autre méthode pour obtenir ce type d'accès que je peux étudier ?

3voto

84104 Points 12538

Une manière "correcte" de faire cela impliquerait de réécrire les scripts d'init pour faire usage de k5start dans les keytabs en mode daemon et per-daemon. Cela permet de s'assurer que le démon en cours d'exécution a accès à un cache d'informations d'identification valide pendant son exécution.

Vous voudrez probablement des principes du style daemon/hostname.domain.tld. Ils sont plus faciles à suivre et plus faciles à gérer pour les keytabs. L'ajout d'une clé à un keytab incrémente automatiquement le numéro de version de la clé (KVNO) et rend aléatoire le "mot de passe" pour ce principe.

1voto

Orion Poplawski Points 11

Si vous exécutez gssproxy, avec une configuration standard de nfs-client comme :

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

Vous pouvez placer le keytab du service dans /var/lib/gssproxy/clients/%UID%.keytab et gssproxy se chargera de créer les tickets pour vous. Cela peut être préférable à l'utilisation de k5start, car ce dernier peut perturber les transitions SELinux.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X