Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

Seb_stien · Le 19/03/2024, à 11:12

Salut tout le monde !

J'ai géré la configuration Kerberos tellement compliquée afin de faire fonctionner NFS.

Mount fonctionne pour les utilisateurs (génial !) mais je rame pour le faire fonctionner pour l'utilisateur root. Je veux pouvoir utiliser les commandes sudo sur le partage nfs.

=== Ce que j'ai fait sur le client ===

*config nfs.conf pour utiliser gssproxy : use-gss-proxy=1

*config /etc/gssproxy/99-nfs-client.conf

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/tmp/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

* envoyer des requêtes de mappage de request-key à nfsidmap

create    id_resolver    *    *    /usr/sbin/nfsidmap -t 600 %k %d

* configurer idmapd.conf avec une résolution statique pour root (cela ne fonctionne pas et n'est pas nécessaire pour mon utilisateur principal -> mystère !)

[Translation]
Method = static,nsswitch
[Static]
root/client.my.domain.com@MY.DOMAIN.COM = root

* configuré une entrée fstab :

nfs_server.my.domain.com:/volume1/TEST   /home/my_user/Bureau/TEST   nfs4   defaults,user,_netdev,nfsvers=4,noauto,sec=krb5   0   0

*Mes keytabs sont les suivants

sudo klist -e -k -t  /etc/krb5.keytab 
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   5 17/03/2024 21:16:16 host/client.my.domain.com@MY.DOMAIN.COM (aes256-cts-hmac-sha1-96) 
   6 16/03/2024 09:15:55 nfs/client.my.domain.com@MY.DOMAIN.COM (aes256-cts-hmac-sha1-96) 

sudo klist -e -k -t /var/lib/gssproxy/clients/my_user.keytab 
Keytab name: FILE:/var/lib/gssproxy/clients/my_user.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   9 17/03/2024 10:13:16 my_user/client.my.domain.com@MY.DOMAIN.COM (aes256-cts-hmac-sha1-96)

sudo klist -e -k -t  /var/lib/gssproxy/clients/root.keytab
Keytab name: FILE:/var/lib/gssproxy/clients/root.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
  11 17/03/2024 21:59:26 root/client.my.domain.com@MY.DOMAIN.COM(aes256-cts-hmac-sha1-96)

=== Résultats ===

Commandes en tant que my_user

mount ./TEST/ -vvv
mount.nfs4: timeout set for Mon Mar 18 15:53:45 2024
mount.nfs4: trying text-based options 'sec=krb5,vers=4.2,addr=[IP NFS SERVER],clientaddr=[IP NFS CLIENT]'
mount.nfs4: mount(2): Protocol not supported
mount.nfs4: trying text-based options 'sec=krb5,vers=4,minorversion=1,addr=[IP NFS SERVER],clientaddr=[IP NFS CLIENT]'
mount.nfs4: mount(2): Protocol not supported
mount.nfs4: trying text-based options 'sec=krb5,vers=4,addr=[IP NFS SERVER],clientaddr=[IP NFS CLIENT]'

cat ./TEST/test2/Fichier_test.txt 
Texte Test dans fichier  : OK

sudo cat ./TEST/test2/Fichier_test.txt 
cat: ./TEST/test2/Fichier_test.txt: Permission non accordée

POURQUOI ?! J'ai fait le même mappage sur le NAS pour root en tant que my_user

Sur le NAS :

sudo cat /etc/idmapd.conf

[Static]
root/client.my.domain.com@MY.DOMAIN.COM=root
my_user/client.my.domain.com@MY.DOMAIN.COM=my_user

 

sudo cat /etc/exports

/volume1/TEST   [IP NFS CLIENT] (rw,async,no_wdelay,crossmnt,insecure,no_root_squash,insecure_locks,sec=krb5,anonuid=1025,anongid=100)

J'ai besoin d'un boss en NFS parce que mes nerfs sont un peu trop éprouvés

Merci !

Seb

Dernière modification par Nuliel (Le 19/03/2024, à 20:05)

iznobe · Le 19/03/2024, à 12:27

Bonjour ,

ton message est indigeste et limite incompréhensible sans les balises codes ...

NFS est basé sur l' UUID / IP_MACHINE .
sur ton serveur , tu peux donc exporté le meme dossier plusieurs fois , vers des IP_MACHINE differentes , avec des parametres differents .donc pour des UUID utilisateurs différents , donc avec des droits différents .

il te suffit donc d ' avoir un fichier /etc/exports tel que :

/volume1/TEST   [IP NFS CLIENT] (rw,async,no_wdelay,crossmnt,insecure,no_root_squash,insecure_locks,sec=krb5,anonuid=1025,anongid=100)
/volume1/TEST   [IP NFS CLIENT SUDO] (rw,async,no_wdelay,crossmnt,insecure,insecure_locks,sec=krb5,anonuid=UUID_ROOT_SERVEUR,anongid=GID_ROOT_SERVEUR)

si mes souvenirs sont bons , y a peut etre d' autre subtilité avec les options .

Seb_stien · Le 19/03/2024, à 18:34

Bonjour iznobe
Merci pour ton retour !
Mais j’ai du mal à comprendre
Aujourd’hui avec cette conf, deux utilisateurs « normaux » arrivent très bien a monter le nfs et récupérer leurs droits distants sans avoir d’exports avec anonuid et anonguid specifiquement definis (une seule déclaration et valeurs fixees comme mentionné)
Ce n’est que l’utilisateur root qui me pose problème
Qu est-ce que je peux te donner comme conf détaillée pour y voir plus clair : l’ensemble des exports? (Je te fais ca en rentrant chez moi)
Mais je crois pas trop à cette cible ; de memoire anonuid et anonguid specifiait les droits pour un user qui n’est pas correctement authentifié (anonyme)

iznobe · Le 20/03/2024, à 10:23

Seb_stien a écrit :

de memoire anonuid et anonguid specifiait les droits pour un user qui n’est pas correctement authentifié (anonyme)

Bonjour , dans ce cas , tu comprends donc facilement pourquoi l' acces aux commandes sudo est systematiquement refusé ...
Peux tu montrer sur le serveur le retour ( avec les balises code hein ... ) de :

showmount -e 127.0.0.1

ou si ca ne fonctionne pas :

showmount -e $HOSTNAME

Dernière modification par iznobe (Le 20/03/2024, à 10:30)

Seb_stien · Le 20/03/2024, à 11:57

voici, avec les balises code

Export list for 127.0.0.1:
/volume1/TEST                 192.168.1.1/24

C'est coherrent avec le /etc/exports.
Et j'arrive tres bien à monter le NFS et récupérer les droits de my_user

Perso je soupçonne gssproxy de s'empetrer avec l'UID 0 de root
En fait pour my_user il crée : /tmp/krb5cc_1000
1000 étant l'ID de my_user

sudo klist -c /tmp/krb5cc_1000 
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: my_user/client.my.domain.com@MY.DOMAIN.COM

Valid starting       Expires              Service principal
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:

Or pour l'user root (uid 0), il y a un krb5cc_0 mais lui ne contient pas un ticket d authentification pour l utilisateur root mais l'authentification du host

sudo klist -c /tmp/krb5cc_0
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/client.my.domain.com@MY.DOMAIN.COM

Valid starting       Expires              Service principal
01/01/1970 01:00:00  01/01/1970 01:00:00  Encrypted/Credentials/v1@X-GSSPROXY:

Qu'est ce que tu en penses ?

J'en profite pour remercier @Nuliel pour la mise en place des balises code dans mon message initial

iznobe · Le 20/03/2024, à 12:37

je ne suis pas un expert du NFS , encore moins avec kerberos ...
si tu desires plusieurs types d' acces NFS , à mon avis il faut creer plusieurs lignes dans le /etc/exports . ne serait ce que pour etre plus securitaire .
j ' ajouterais une ligne dans le genre de celle deja decrite precedemment .
ou bien remplacerai pour faire des tests .
il faudra aussi creer la securité pour l' user devant disposer de l' acces aux commandes sudo . je ne vois pas vraiment d' autre solution .
de plus pour la maintenance / evolution des choses , c ' est bien plus propre et clair .

Dernière modification par iznobe (Le 20/03/2024, à 12:37)

Seb_stien · Le 20/03/2024, à 12:55

J'ai une bonne piste :
le ticket "root" contient en fait un ticket host.
Du coup le mapping du nas :

root/client.my.domain.com@MY.DOMAIN.COM=root

ne peut pas s'appliquer car lors de la commande

sudo cat ./TEST/test2/Fichier_test.tx

L'utilisateur root présente en fait le ticket host

Si je réalise le montage NFS et qu apres montage, j'ajoute un mapping sur le nas

host/client.my.domain.com@MY.DOMAIN.COM=root

J'arrive à lancer ma commande sudo !

sudo cat ./TEST/test2/Fichier_test.txt 
Texte Test dans fichier

Du coup j'ai pensé à laisser le mapping côté NAS

host/client.my.domain.com@MY.DOMAIN.COM=root

Le problème c'est que le ticket host dans /tmp/krb5cc_0 est utilisé lors du montage initial NFS : la commande mount va utiliser ce ticket host et n'aime pas le mappage vers root côté nas ; du coup le NFS n'est plus monté si la regle de mapping host<-> root reste dès le debut

Peut etre faut il trouver un moyen que GSS proxy n'utilise pas l'utilisateur root pour stocker le ticket host dans /tmp/krb5cc_0 ?

Quelle galère !

iznobe · Le 20/03/2024, à 13:03

tu devrais peut etre utiliser un user disposant de l' acces sudo plutot que root . c ' est toujours preferable et ca serait peut etre plus simple de regler le soucis de ton ticket .

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 19/03/2024, à 11:12

Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#2 Le 19/03/2024, à 12:27

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#3 Le 19/03/2024, à 18:34

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#4 Le 20/03/2024, à 10:23

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#5 Le 20/03/2024, à 11:57

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#6 Le 20/03/2024, à 12:37

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#7 Le 20/03/2024, à 12:55

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

#8 Le 20/03/2024, à 13:03

Re : Besoin d'un expert sur NFS Kerberos ! Mappage de l'utilisateur root

Pied de page des forums