NFSv4 und Kerberos: Keine Berechtigung

[wuesten.fuchs]

Hallo Gemeinde,
ich betreibe hier einen Kerberos Dienst und will einen NFS-Server anbinden, was soweit auch klappt.

Nun soll ein weiterer Server beim Systemstart automatisch auf NFS-Freigaben zugreifen können. Und hier beginnt es zu haken. Kurz: Wenn ich mich am NFS-Client als normaler Benutzer anmelde und mir mit "kinit" ein Kerberos Ticket hole, kann ich problemlos lesend und schreibend auf diese Freigaben zugreifen, sofern die Besitzrechte stimmen.

Will ich aber als root darauf zugreifen, kann ich nur lesend darauf zugreifen. Will ich auch schreiben, kommt folgendes:


root@nfs-client:~# touch /srv/ssl/test
touch: kann „/srv/ssl/test“ nicht berühren: Keine Berechtigung


Hier die Dateiberechtigungen:

root@nfs-client:~# ls -la /srv/ssl/
insgesamt 12
drwxr-xr-x 3 root root 4096 2011-08-01 21:01 .
drwxr-xr-x 5 root root 4096 2011-07-31 21:08 ..
-rw-r--r-- 1 root root 0 2011-08-01 21:01 te

und ja, owner und group sind wirklich root:

root@nfs-client:~# ls -lan /srv/ssl/
insgesamt 12
drwxr-xr-x 3 0 0 4096 2011-08-01 21:01 .
drwxr-xr-x 5 0 0 4096 2011-07-31 21:08 ..
-rw-r--r-- 1 0 0 0 2011-08-01 21:01 te

Die uids und gids sind auf NFS server und NFS client gleich.

Hier meine /etc/exports:

/export gss/krb5p(rw,fsid=0,insecure,no_subtree_check,async)
/export/ssl gss/krb5p(rw,nohide,insecure,no_subtree_check,async,no _root_squash)


Und die fstab auf dem client:

nfs-server.example.com:/ssl /srv/ssl nfs4 rw,sec=krb5p,hard,intr 0 0

Ein Kerberos Maschinen-Ticket ist auf dem Client vorhanden:

root@nfs-client:~# klist /tmp/krb5cc_machine_EXAMPLE.COM
Ticket cache: FILE:/tmp/krb5cc_machine_EXAMPLE.COM
Default principal: nfs/nfs-client.example.com@EXAMPLE.COM

Valid starting Expires Service principal
08/01/11 21:46:53 08/02/11 07:46:53 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 08/02/11 21:46:53
08/01/11 21:46:53 08/02/11 07:46:53 nfs/nfs-server.example.com@EXAMPLE.COM
renew until 08/02/11 21:46:53


Egal, mit welcher Verbosity ich sowohl den KDC, als auch sämtliche NFS-Daemonen sowohl auf Server-, als auch auf Client-Seite laufen lasse, es kommt keine Fehlermeldung, bis auf die folgende (und die sagt nix anderes, als dass ein Berechtigungsproblem vorliegt, was ich ja im Terminal schon gesehen hab):

fh_verify: //ssl permission failure, acc=3, error=13

Ich bin mir ziemlich sicher, dass es kein Kerberos-Problem ist, sondern ein "simples" Berechtigungsproblem im NFS. Aber ich kann mir nicht erklären, woher das Problem kommt, denn die üblichen Verdächtigen (unterschiedliche uids, Dienste nicht alle gestartet, usw) scheinen ja ok zu sein.

Hier meine /etc/krb5.conf:

[libdefaults]
allow_weak_crypto = true

[realms]
EXAMPLE.COM = {
kdc = kerberos.example.com
admin_server = kerberos.example.com
master_kdc = kerberos.example.com
default_domain = example.com
}

[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

[login]
krb4_convert = false
krb4_get_tickets = false

/etc/default/nfs-kernel-server:

RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS=--manage-gids
NEED_SVCGSSD=yes
RPCSVCGSSDOPTS=

/etc/default/nfs-common:

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes

Hab ich eine Konfigurationsdatei vergessen?

Das Ganze läuft unter stock Ubuntu 10.04.3 mit den neuesten Patches.

Wäre nett, wenn jemand eine Idee hätte, warum mir der Client fehlerhafte Berechtigungen vorwirft, obwohl alles zu stimmen scheint. Bin echt langsam ratlos...

[wuesten.fuchs]

Okay, wenn ich die Berechtigungen für den Ordner /srv/ssl auf 777 ändere und dann ein 'touch test' durchführe, passiert folgendes:


root@nfs-client:~# touch /srv/ssl/test

root@nfs-client:~# ls -la /srv/ssl/
insgesamt 8
drwxr-xr-x 2 root root 4096 2011-08-02 07:04 .
drwxr-xr-x 5 root root 4096 2011-07-31 21:08 ..
-rw-r--r-- 1 root root 0 2011-07-31 21:43 te
-rw-r--r-- 1 nobody nogroup 0 2011-08-02 07:04 test

root@nfs-client:~# ls -lan /srv/ssl/
insgesamt 8
drwxr-xr-x 2 0 0 4096 2011-08-02 07:04 .
drwxr-xr-x 5 0 0 4096 2011-07-31 21:08 ..
-rw-r--r-- 1 0 0 0 2011-07-31 21:43 te
-rw-r--r-- 1 65534 65534 0 2011-08-02 07:04 test

Die /etc/idmapd.conf schaut so aus:

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = example.com

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

Warum bloß wird root auf Nobody gemappt?

[wuesten.fuchs]

Drei Beobachtungen:

1. Wenn ich direkt vom NFS-Server aus auf die NFS-Share zugreifen will (also von derselben Maschine aus), schlägt der Zugriff dennoch fehl. uid und gid sind in diesem Fall hundertprozentig gleich.

2. Wenn ich mir ein Kerberos-Principal für den Benutzer root einrichte, ein Kerberos-Ticket löse und versuche, eine Datei zu erstellen, werde ich dennoch auf 'nobody/nogroup' gemappt:


root@nfs-client:~# kinit root

root@nfs-client:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: root@EXAMPLE.COM

Valid starting Expires Service principal
08/02/11 20:55:09 08/03/11 06:55:09 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 08/03/11 20:55:05

root@nfs-client:~# touch /mnt/ssl/test2
root@nfs-client:~# ls -l /mnt/ssl/
insgesamt 0
-rw-r--r-- 1 nobody nogroup 0 2011-08-02 20:55 test2


3. Wenn ich die Exports auf nativ (also ohne Kerberos) umstelle, funktioniert der Zugriff wunderbar:

/etc/exports:

/export *(rw,fsid=0,insecure,no_subtree_check,async)
/export/ssl *(rw,nohide,insecure,no_subtree_check,async,no_roo t_squash)


root@nfs-client:~# touch /mnt/ssl/test3
root@nfs-client:~# ls -l /mnt/ssl/
insgesamt 0
-rw-r--r-- 1 root root 0 2011-08-02 20:55 test3

Es scheint, als ob das user mapping bzw. root squashing irgendwo aus dem Ruder läuft...

Hat jemand Erfahrung damit?

[hzensne1]

Hallo Wüsten-Fuchs,
dein Thema ist ja nun schon etwas länger her, aber hast du denn inzwischen eine Lösung deines Problems?

Ich habe auf meinem Heimserver ebenfalls versucht nfsv4 mit Kerberos zu sichern, was auch prima funktioniert hat. Die Root-Problematik kenne ich aber auch und da mein Heimserver auch ein rsync-Ziel ist, war das Schreiben als root zwingend notwendig. Letztlich habe ich mich entschieden ohne Kerberos weiter zu machen, würde das Thema aber gerne noch mal aufgreifen, da eigentlich alles wunderbar funktioniert (nfs, dhcp, bind9, ...) nur eben Kerberos nicht - zumindest nicht in Verbindung mit NFSv4.

Gruß