Berechtigungen werden mit Kerberised NFSv4 unter FreeBSD nicht wirksam


7

Ich versuche derzeit, einen NFSv4-Server unter FreeBSD einzurichten. Ich habe umfangreiche Erfahrung damit auf anderen Unices (Solaris und Linux), aber ich bin ziemlich neu in FreeBSD.

Mein Ziel ist es, Folgendes zu erreichen:

  • Vom FreeBSD-System bereitgestellte Dateien
  • Das einzige Sicherheitsmodell sollte krb5p sein
  • Clients sind Linux (Ubuntu) und OSX

Derzeit habe ich es geschafft, die Dinge so einzurichten, dass ich ein gültiges TGT benötige, um auf das Dateisystem zugreifen zu können. Nach dem Versuch, auf diese Dateien zuzugreifen, kann ich klistauf dem Client ausgeführt werden und feststellen, dass der nfs/domainnamePrincipal abgerufen wurde. Dies deutet darauf hin, dass der Kerberos-Teil des NFS-Mount korrekt ist.

Mein Problem ist, dass alle Clientzugriffe weiterhin über den nobodyBenutzer ausgeführt werden. Ich kann die Berechtigungen sehen, wenn ich es tue ls -l. Sogar die Benutzerzuordnung funktioniert ordnungsgemäß, aber wenn nobodyich keine Berechtigung habe, etwas mit den Dateien zu tun, wird mir eine Berechtigung verweigert.

Hier ist eine Beispielinteraktion vom Client (in diesem Fall Ubuntu, aber dasselbe passiert unter OSX). In diesem Beispiel /export/shared/testshareist das freigegebene Verzeichnis vom FreeBSD-Server:

(Ich habe den tatsächlichen Domainnamen in domainund den Kerberos-Realmnamen in geändert. REALM)

$ kinit
Password for elias@REALM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
$ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare /mnt
$ ls -l /mnt
total 4
-rw-r--r-- 1 nobody nogroup   5 Feb  7 18:17 bar.txt
-rw------- 1 elias  nogroup   4 Feb  5 23:09 foo.txt
$ cat /mnt/bar.txt
blah
$ echo foo >>/mnt/bar.txt
bash: /mnt/bar.txt: Permission denied
$ cat /mnt/foo.txt
cat: /mnt/foo.txt: Permission denied
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
09/02/2013 09:41:56  10/02/2013 09:40:44  nfs/lion.domain@REALM

Serverkonfiguration

Ich hatte einige Probleme, einen umfassenden Leitfaden zum Einrichten von NFSv4 unter FreeBSD zu finden. Dies ist an sich schon etwas überraschend, da ich festgestellt habe, dass Informationen darüber, wie man Dinge in FreeBSD macht, sehr gut sind.

Hier sind die relevanten Zeilen in /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
mountd_enable="YES"
gssd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
zfs_enable="YES"

Hier ist der Inhalt von /etc/exports:

/export/shared/testshare -sec=krb5p
V4: / -sec=krb5p

Ein weiterer interessanter Aspekt ist, dass ich tcpdumpbeim Aufzeichnen des NFS-Netzwerkverkehrs zwischen Client und Server NFS3- Pakete zusammen mit den NFS4- Paketen gesehen habe. Beide Pakettypen enthielten verschlüsselte Daten, daher denke ich immer noch, dass Kerberos verwendet wurde, aber angesichts der obigen Konfiguration hätte ich erwartet, dass es nur NFS4-Verkehr gibt.

Antworten:


0
  1. Müssen nfs3 mit deaktivieren vfs.nfsd.server_min_nfsvers=4.
  2. Um "niemanden" zu vermeiden, sollten sich NFSv4-Client und -Server im selben Domänenbereich befinden .

Ich habe bereits Nummer 1 gemacht und es hatte keine Wirkung. Beziehen Sie sich bei Nummer 2 auf die DNS-Domäne oder den Kerberos-Bereich?
Elias Mårtenson

Entschuldigung, ich meinte "Reich". Natürlich sollte es nicht notwendig sein, aber es war einfach, wenn möglich. Eine knappe Sekunde ist das Hinzufügen zu "Local-Realms" in der idmapd.conf.
Igelkott

Sie befinden sich jedoch beide im selben Bereich (und in derselben Domäne).
Elias Mårtenson

0

Einfach ausgedrückt muss es eine Möglichkeit geben, Benutzernamen zwischen den Systemen zuzuordnen. Führen Sie idmapd sowohl auf dem Server als auch auf dem Client aus? Ldap?

Versuchen Sie zumindest als Test, bestimmte Zuordnungen zwischen Namen vorzunehmen ... außer zunächst root.


Das Mapping funktioniert. Ich bekomme die richtigen Benutzernamen angezeigt. Die tatsächlich angewendeten Berechtigungen gelten jedoch für "niemanden".
Elias Mårtenson

Also, alles funktioniert, aber es schlägt immer noch fehl. Entschuldigung, ich konnte nicht wirklich helfen.
igelkott

0

Ich habe das Problem gelöst. Nachdem ich den Code durchgesehen hatte, stellte ich fest, dass die Ursache ein Fehler in der GSS-Bibliothek war. Das Problem wurde durch einen getpwnam_rzu kleinen Puffer verursacht .

Alle Details finden Sie in der Diskussion auf der Mailingliste

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.