Setup zum Mounten des kerberisierten nfs-Ausgangsverzeichnisses - gssd findet kein gültiges Kerberos-Ticket

Unsere Home-Verzeichnisse werden über kerberized nfs exportiert, sodass der Benutzer ein gültiges Kerberos-Ticket benötigt, um sein Home mounten zu können. Dieses Setup funktioniert einwandfrei mit unseren vorhandenen Clients und Servern.

Jetzt wollen wir einen 11.10-Client hinzufügen und so ldap & kerberos zusammen mit pam_mount einrichten. Die ldap-Authentifizierung funktioniert und Benutzer können sich über ssh anmelden, ihre Häuser können jedoch nicht gemountet werden.

Wenn pam_mount für das Mounten als Root konfiguriert ist, findet gssd kein gültiges Kerberos-Ticket und das Mounten schlägt fehl.

Nov 22 17:34:26 zelda rpc.gssd[929]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
Nov 22 17:34:26 zelda rpc.gssd[929]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt2)
Nov 22 17:34:26 zelda rpc.gssd[929]: process_krb5_upcall: service is '<null>'
Nov 22 17:34:26 zelda rpc.gssd[929]: getting credentials for client with uid 0 for server purple.physcip.uni-stuttgart.de
Nov 22 17:34:26 zelda rpc.gssd[929]: CC file '/tmp/krb5cc_65678_Ku2226' being considered, with preferred realm 'PURPLE.PHYSCIP.UNI-STUTTGART.DE'
Nov 22 17:34:26 zelda rpc.gssd[929]: CC file '/tmp/krb5cc_65678_Ku2226' owned by 65678, not 0
Nov 22 17:34:26 zelda rpc.gssd[929]: WARNING: Failed to create krb5 context for user with uid 0 for server purple.physcip.uni-stuttgart.de
Nov 22 17:34:26 zelda rpc.gssd[929]: doing error downfall

Wenn pam_mount andererseits mit der Option noroot = 1 konfiguriert ist, kann das Volume überhaupt nicht gemountet werden.

Nov 22 17:33:58 zelda sshd[2226]: pam_krb5(sshd:auth): user phy65678 authenticated as phy65678@PURPLE.PHYSCIP.UNI-STUTTGART.DE
Nov 22 17:33:58 zelda sshd[2226]: Accepted password for phy65678 from 129.69.74.20 port 51875 ssh2
Nov 22 17:33:58 zelda sshd[2226]: pam_unix(sshd:session): session opened for user phy65678 by (uid=0)
Nov 22 17:33:58 zelda sshd[2226]: pam_mount(mount.c:69): Messages from underlying mount program:
Nov 22 17:33:58 zelda sshd[2226]: pam_mount(mount.c:73): mount: only root can do that
Nov 22 17:33:58 zelda sshd[2226]: pam_mount(pam_mount.c:521): mount of /Volumes/home/phy65678 failed

Wie können wir Benutzern einer bestimmten Gruppe erlauben, nfs-Bereitstellungen durchzuführen? Wenn dies nicht funktioniert, können wir pam_mount dazu bringen, root zu verwenden, aber die richtige UID zu übergeben?

— jan bernlöhr
quelle

Dasselbe Problem gilt für das -osec=krb5

— Aktivieren von

In der Tat ist dieses Problem noch nicht gelöst. Soll ich eine andere Frage mit dem gleichen Titel und Inhalt erstellen oder was meinst du mit "repost"?

— Jan Bernlöhr

Ich dachte, mit kerberized nfs mounten Sie als root (mit dem System-Keytab), aber der Dateizugriff erfolgt mit dem Ticket jedes Benutzers.

— Jayen

Abfrage Kommentar entfernt - wird überwachen

— Ringtail

Steigst du /home /home/useroder /home/user/mountpoint? Der erste muss meiner Meinung nach vor dem Login gemacht werden. Das zweite Mal habe ich versucht, es mit sshfs zu tun, aber es schlug bei der Anmeldung mit GDM und LightDM immer wieder fehl, und ich glaube nicht, dass es die Schuld von sshfs war. Das dritte sollte funktionieren, Sie müssen nur den Benutzer zu einer Gruppe hinzufügen, die NFS-Mounts ausführen darf. Bitte lassen Sie mich wissen, wenn Sie den zweiten zum Laufen bringen. Das würde mich interessieren.

— d_inevitable

Siehe diesen Thread:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190267

Wenn es in fstab keine Option "user" gibt, kann nur root Volumes mounten. In mount.c gibt es einen Kommentar dazu, wie der Befehl mount von jedem Benutzer ausführbar gemacht werden kann, der jedoch vom Betreuer abgelehnt wurde (der Kommentar sagt etwas über die Auswirkungen auf die Sicherheit aus, ist aber nicht spezifischer).

Im Gegensatz zum ursprünglichen Upstream führt die Debian-Version von libpam-mount mount-Befehle mit der Benutzer- UID aus, nicht als root. Das Ausführen von benutzerdefinierten Reitern als Root ist eine Sicherheitslücke. Jeder Benutzer kann dann beim Anmelden ein Volume in / usr oder / tmp mounten oder beim Abmelden ein anderes Volume ummounten.

Mit anderen Worten, libpam-mount kann nur Dinge tun, die der Benutzer tun kann, sonst nichts.

Also irgendwelche Vorschläge?

Das Einfügen eines Benutzereintrags in fstab sollte dies tun. Bitte sagen Sie mir, wie das funktioniert. Beachten Sie, dass andere Dateisysteme (ncp, smb) vom Benutzer aufrufbare Mount-Binärdateien wie smbmount oder ncpmount haben. Für Loopback-Reittiere scheint es nichts Vergleichbares zu geben: /

— Aleksander Adamowski
quelle