3
NFS und Gruppenrechte
Moin,
debian Squeeze Server + Client sind per NFS verbunden
Der NFS Server soll als Datencotainer laufen.
Es gibt verschiedenen Gruppen, die vom Client kontroliert werden (User + Gruppen ohne LDAD etc)
Ordner und Datein sind im Beispiel auf 770 und root.info bzw dietz.info gesetzt:
testdat.dat läßt sich nicht öffnen
testdietz.dat läßt sich öffnen
obwohl dietz in der Gruppe info ist
Habe ich aus Clientsicht auf dem Server überhaupt "Gruppenrechte"?
Ich habe verschiedene Mount und Exportseinstellungen geprüft und komme nicht weiter.
Das Problem existiert aus meiner Sicht erst mit debian Squeeze.
Ein erster Hinweis wo es weitergeht wäre toll.
exports
fstab
debian Squeeze Server + Client sind per NFS verbunden
Der NFS Server soll als Datencotainer laufen.
Es gibt verschiedenen Gruppen, die vom Client kontroliert werden (User + Gruppen ohne LDAD etc)
Ordner und Datein sind im Beispiel auf 770 und root.info bzw dietz.info gesetzt:
dietz@vepdc:~$ ls -l /var/data/nfs/data01/test/
insgesamt 12
-rwxrwx--- 1 root info 4 6. Aug 12:10 testdat.dat
-rwxrwx--- 1 dietz info 4 6. Aug 13:20 testdietz.dattestdat.dat läßt sich nicht öffnen
testdietz.dat läßt sich öffnen
obwohl dietz in der Gruppe info ist
dietz@vepdc:~$ cat /etc/group | grep info
info:x:1001:dietz,dietz-vm,x-apps,janssenHabe ich aus Clientsicht auf dem Server überhaupt "Gruppenrechte"?
Ich habe verschiedene Mount und Exportseinstellungen geprüft und komme nicht weiter.
Das Problem existiert aus meiner Sicht erst mit debian Squeeze.
Ein erster Hinweis wo es weitergeht wäre toll.
exports
# to NFS clients. See exports(5).
/export/backup01 192.168.5.0/24(rw,subtree_check,secure,no_root_squash,sync)
/export/data01 192.168.5.0/24(rw,no_subtree_check,no_root_squash)
/export/stadata 192.168.5.0/24(rw,subtree_check,secure)
# NFSv4 - pseudo filesystem root
/export 192.168.5.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)
/export 192.168.5.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)
/export 192.168.5.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)fstab
#nfs NAS
192.168.5.1:/export/data01 /var/data/nfs/data01 nfs rw,auto,rsize=32768,wsize=32768,hard,intr,tcp,nolock 0 0
#
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 189159
Url: https://administrator.de/contentid/189159
Printed on: April 19, 2024 at 19:04 o'clock
3 Comments
Latest comment
Hallo,
die testdat.dat gehoert root, und die testdat.dat~ ist eine kopie davon.
Nachdem Zeitstempel sind ja beide Datein gleichzeitig angelegt wurden?
Desweiteren stellt sich die Frage der uebergeordneten Rechte?
Wurden die Recursiv vergeben? also chmod -R 770 /dein/pfad
Ich wuerde hier mal eine neue Datei anlegen mit dem user dietz.
Ansonsten sehen die Mounts und Optionen auf den ersten Blick ok aus.
Gruss
die testdat.dat gehoert root, und die testdat.dat~ ist eine kopie davon.
Nachdem Zeitstempel sind ja beide Datein gleichzeitig angelegt wurden?
Desweiteren stellt sich die Frage der uebergeordneten Rechte?
Wurden die Recursiv vergeben? also chmod -R 770 /dein/pfad
Ich wuerde hier mal eine neue Datei anlegen mit dem user dietz.
Ansonsten sehen die Mounts und Optionen auf den ersten Blick ok aus.
Gruss
Und je nach Menge der User solltest Du Dich zum Thema ACL's einlesen...
Lonesome Walker
Lonesome Walker
Das Ergebnis der weiteren Tests bestätigt die Beobachtung: unter Debian
Etch hat der NFS-Server die Gruppenmitgliedschaft schlicht nicht
richtig überprüft und das dem Client überlassen.
Das entsprach auch nicht dem Internet-Standard (RFC) für NFS:
http://tools.ietf.org/html/rfc1813#section-1.5
Das Problem schien darin zu bestehen, wie Etch bei
NFS-Protokoll-Version 2 die Gruppenmitgliedschaften behandelt
hat. Dies wurde bei Squeeze "richtig" implementiert. Daher geht es
auch bei Squeeze weder mit NFS-Protokoll-Version 2 noch mit v3 (v3
ist inzwischen Standard beim Mounten).
Beispiel für Mounten mit Protokollversion 3, Server ist Squeeze:
Nun auf dem Client (Proto v3):
Mountet man dasselbe Verzeichnis mit Protokollversion v2 anstelle von
v3 gibt es nur eine andere Fehlermeldung:
Kurz: das Verhalten von Squeeze ist korrekt (RPC-konform), und ich
sehe keine Möglichkeit, das entsprechend zu ändern (wie
vermutet). Auch das RFC selber sagt deutlich, dass auf Client und
Server die Zuordnung von Usern und Gruppen sowohl von den Namen als
auch von den IDs her übereinstimmen muss, damit Rechte richtig
funktionieren:
Etch hat der NFS-Server die Gruppenmitgliedschaft schlicht nicht
richtig überprüft und das dem Client überlassen.
Das entsprach auch nicht dem Internet-Standard (RFC) für NFS:
http://tools.ietf.org/html/rfc1813#section-1.5
Das Problem schien darin zu bestehen, wie Etch bei
NFS-Protokoll-Version 2 die Gruppenmitgliedschaften behandelt
hat. Dies wurde bei Squeeze "richtig" implementiert. Daher geht es
auch bei Squeeze weder mit NFS-Protokoll-Version 2 noch mit v3 (v3
ist inzwischen Standard beim Mounten).
Beispiel für Mounten mit Protokollversion 3, Server ist Squeeze:
[0 root@debian-squeeze /export] ls -l
total 12
-rw-rw---- 1 root 40022 6 7. Aug 04:50 owned-by-auxiliary-group
-rw-rw---- 1 root 40021 7 7. Aug 04:50 owned-by-primary-group
-rw-rw---- 1 root 40023 8 7. Aug 04:51 owned-by-third-groupNun auf dem Client (Proto v3):
[0 root@chai-latte /] mount 192.168.10.121:/export /mnt -o nfsvers=2
[0 root@chai-latte /] cd /mnt
[0 root@chai-latte /mnt] ls -l
total 12
-rw-rw---- 1 root auxiliary-group 6 Aug 7 10:50 owned-by-auxiliary-group
-rw-rw---- 1 root primary-group 7 Aug 7 10:50 owned-by-primary-group
-rw-rw---- 1 root third-group 8 Aug 7 10:51 owned-by-third-group
[0 root@chai-latte /mnt] su - normaluser
normaluser@chai-latte:~$ groups
primary-group auxiliary-group
normaluser@chai-latte:~$ cd /mnt
normaluser@chai-latte:/mnt$ ls -l
total 12
-rw-rw---- 1 root auxiliary-group 6 Aug 7 10:50 owned-by-auxiliary-group
-rw-rw---- 1 root primary-group 7 Aug 7 10:50 owned-by-primary-group
-rw-rw---- 1 root third-group 8 Aug 7 10:51 owned-by-third-group
normaluser@chai-latte:/mnt$ cat owned-by-primary-group
chunky
normaluser@chai-latte:/mnt$ cat owned-by-auxiliary-group
cat: owned-by-third-group: Permission denied
normaluser@chai-latte:/mnt$ cat owned-by-third-group
cat: owned-by-third-group: Permission deniedMountet man dasselbe Verzeichnis mit Protokollversion v2 anstelle von
v3 gibt es nur eine andere Fehlermeldung:
normaluser@chai-latte:/mnt$ cat owned-by-primary-group
chunky
normaluser@chai-latte:/mnt$ cat owned-by-auxiliary-group
cat: owned-by-auxiliary-group: Input/output error
normaluser@chai-latte:/mnt$ cat owned-by-third-group
cat: owned-by-third-group: Permission deniedKurz: das Verhalten von Squeeze ist korrekt (RPC-konform), und ich
sehe keine Möglichkeit, das entsprechend zu ändern (wie
vermutet). Auch das RFC selber sagt deutlich, dass auf Client und
Server die Zuordnung von Usern und Gruppen sowohl von den Namen als
auch von den IDs her übereinstimmen muss, damit Rechte richtig
funktionieren:
Using user ids and group ids implies that the client and server
either share the same ID list or do local user and group ID mapping.
Servers and clients must agree on the mapping from user to uid and
from group to gid, for those sites that do not implement a
consistent user ID and group ID space.
either share the same ID list or do local user and group ID mapping.
Servers and clients must agree on the mapping from user to uid and
from group to gid, for those sites that do not implement a
consistent user ID and group ID space.
