Hallo,
ich versuche gerade von einem Fedora 10 Client (der unter coLinux läuft, falls das irgendwie von Bedeutung ist) auf eine NFS Freigabe zu schreiben. Aber egal wer ich gerade bin (root, normaler Benutzer), die UID/GID der neu erzeugten Datei ist immer nobody:nogroup.
Da ich keine Möglichkeit gefunden habe, unter Fedora einen NFS-mount über sichere Ports abzuwickeln, ist das Verzeichnis auf dem Server mit der Option "insecure" exportiert.
Hier die Schritte auf dem Clienten zum Nachvollziehen: # mount serverip:/exported/filesystem /mnt/server $ cd /mnt/server/tmp tmp hat die Berechtigung -rwxrwxrwx $ touch test $ ls -l test -rw-r--r-- 1 65534 65534 0 4. Mär 11:43 test nobody nogroup
Die gleichen Schritte von einem OpenSUSE liefern wie erwartet -rw-r--r-- 1 uid gid 0 4. Mär 11:43 test
Der angeführte mount ist auch der einzige und dass er grundsätzlich die richtigen Optionen vom Server benutzt ist nachgewiesen, weil es ohne die 'insecure' Option der Mount gar nicht funktioniert.
Zwei Fragen, die eventuell weiterhelfen können: - gibt es eine Möglichkeit mount anzuweisen sichere Ports zu benutzen? - wenn es ein Sicherheitsfeature ist, dass fedora die uid schon auf Clientseite ändert: kann ich das irgendwie ausschalten?
Besten Dank Uwe
Hallo Use,
Uwe Koloska koloska@voiceinterconnect.de (Do 04 Mär 2010 12:16:58 CET):
Hallo,
ich versuche gerade von einem Fedora 10 Client (der unter coLinux läuft, falls das irgendwie von Bedeutung ist) auf eine NFS Freigabe zu schreiben. Aber egal wer ich gerade bin (root, normaler Benutzer), die UID/GID der neu erzeugten Datei ist immer nobody:nogroup.
(…)
Hier die Schritte auf dem Clienten zum Nachvollziehen: # mount serverip:/exported/filesystem /mnt/server $ cd /mnt/server/tmp tmp hat die Berechtigung -rwxrwxrwx $ touch test $ ls -l test -rw-r--r-- 1 65534 65534 0 4. Mär 11:43 test nobody nogroup
Eigentlich ein Verhalten, das als „root_squash“ bekannt ist, und, wenn es für alle Nutzer gilt, dann als „all_squash“. Default ist beim Export „root_squash“. Das dürfte für normale Nutzer nicht gelten, insofern etwas eigentartig.
Eigentlich kann der Client den Owner nicht änden, so lange er nicht root-Rechte hat. Und diese helfen auch nur, wenn eben „no_root_squash“ beim Export gesetzt ist.
1) Vor dem touch war die Datei noch nicht vorhanden? (eventuell durch ein vorheriges touch als root) -> ein besserer Test wäre hier „mkdir test“, da gäbe es deutlichere Anzeichen bei Mißerfolg.
2) Was macht ein „mkdir /tmp/test“ als der selbe Nutzr, der „mkdir /mnt/server/tmp/test“ macht?
Hallo Heiko,
Am Donnerstag 04 März 2010 schrieb Heiko Schlittermann:
ich versuche gerade von einem Fedora 10 Client (der unter coLinux läuft, falls das irgendwie von Bedeutung ist) auf eine NFS Freigabe zu schreiben. Aber egal wer ich gerade bin (root, normaler Benutzer), die UID/GID der neu erzeugten Datei ist immer nobody:nogroup.
(…)
Hier die Schritte auf dem Clienten zum Nachvollziehen: # mount serverip:/exported/filesystem /mnt/server $ cd /mnt/server/tmp tmp hat die Berechtigung -rwxrwxrwx $ touch test $ ls -l test -rw-r--r-- 1 65534 65534 0 4. Mär 11:43 test nobody nogroup
Eigentlich ein Verhalten, das als „root_squash“ bekannt ist, und, wenn es für alle Nutzer gilt, dann als „all_squash“. Default ist beim Export „root_squash“. Das dürfte für normale Nutzer nicht gelten, insofern etwas eigentartig.
Das weiß ich schon, hätte es aber natürlich noch erwähnen müssen, denn die Nicht-Beachtung dieser Optionen ist ja gerade das, was ich hier nicht verstehe. Ausgangspunkt der ganzen Suche ist, dass ich ein root-fs für einen anderen Rechner von der coLinux Maschine (Fedora 10) auf den Server (Debian 4) übertragen wollte. Dazu sollten natürlich alle Nutzer und Nutzerrechte erhalten bleiben. Deshalb habe ich natürlich zuerst "no_root_squash" konfiguriert. Der root konnte trotzdem noch nicht auf das Serververzeichnis zugreifen. Da habe ich angefangen, zum Test Dateien mit touch zu erzeugen. Das hat erst funktioniert, nachdem ich das Verzeichnis für alle zum Schreiben freigegeben habe. Daraufhin habe ich dann auch als normaler Nutzer den Test gemacht, wieder mit dem Ergebnis, dass die Datei nobody/nogroup gehört.
Nächste Option war dann folgerichtig "no_all_squash". Aber auch das ohne Erfolg.
Eigentlich kann der Client den Owner nicht änden, so lange er nicht root-Rechte hat. Und diese helfen auch nur, wenn eben „no_root_squash“ beim Export gesetzt ist.
- Vor dem touch war die Datei noch nicht vorhanden? (eventuell durch ein vorheriges touch als root)
Die Datei habe ich vorher jedesmal gelöscht oder eine andere gewählt.
-> ein besserer Test wäre hier „mkdir test“, da gäbe es deutlichere Anzeichen bei Mißerfolg.
Was gibt es denn da für deutlichere Anzeichen?
- Was macht ein „mkdir /tmp/test“ als der selbe Nutzr, der „mkdir /mnt/server/tmp/test“ macht?
?? Wo soll ich den ersten Befehl ausführen?
Und wie gesagt: Das ganze Prozedere liefert genau die erwarteten Ergebnisse, wenn der Client, der das Verzeichnis mounted ein openSUSE 10.3 ist. Die Serverkonfiguration sollte also eigentlich korrekt sein.
Ich kann mir eigentlich nur vorstellen, dass der NFS Client von Fedora 10 schon einige NFS4 Eigenschaften nutzt (was unwahrscheinlich ist, da nfs4 beim Mounten explizit ausgewählt werden muss). Dort gibt es aber einen Dämon, der die Nutzer umschreibt (Name müsste ich morgen nachgucken). Der ist nur für nobody/nogroup konfiguriert.
Eine andere Alternative wären die Sicherheitseinstellungen, obwohl SELinux anscheinend gar nicht aktiviert ist.
Ich hab' keine weitere Idee.
Viele Grüße Uwe
Uwe Koloska ml@koloro.de (Do 04 Mär 2010 23:11:24 CET):
Hallo Heiko,
Am Donnerstag 04 März 2010 schrieb Heiko Schlittermann:
(…)
Eigentlich ein Verhalten, das als „root_squash“ bekannt ist, und, wenn es für alle Nutzer gilt, dann als „all_squash“. Default ist beim Export „root_squash“. Das dürfte für normale Nutzer nicht gelten, insofern etwas eigentartig.
Das weiß ich schon, hätte es aber natürlich noch erwähnen müssen, denn die Nicht-Beachtung dieser Optionen ist ja gerade das, was ich hier nicht
(…)
anderen Rechner von der coLinux Maschine (Fedora 10) auf den Server (Debian 4) übertragen wollte. Dazu sollten natürlich alle Nutzer und Nutzerrechte erhalten bleiben. Deshalb habe ich natürlich zuerst "no_root_squash" konfiguriert. Der root konnte trotzdem noch nicht auf das Serververzeichnis zugreifen.
Das ist merkwürdig.
(…)
-> ein besserer Test wäre hier „mkdir test“, da gäbe es deutlichere Anzeichen bei Mißerfolg.
Was gibt es denn da für deutlichere Anzeichen?
Wenn das Objekt schon vorhanden ist, mault es. Und wenn's geht, kannst Du bedenkenlos das leere Verzeichnis wieder löschen. Wenn Du das mit touch machst auf eine schon vorhandene (aber wichtige) Datei, wäre das böse.
- Was macht ein „mkdir /tmp/test“ als der selbe Nutzr, der „mkdir /mnt/server/tmp/test“ macht?
?? Wo soll ich den ersten Befehl ausführen?
Auf dem Client. Einfach ums zu sehen, wer Du bist. (id sollte es auch tun, aber man weiß ja nie…)
Ich kann mir eigentlich nur vorstellen, dass der NFS Client von Fedora 10 schon einige NFS4 Eigenschaften nutzt (was unwahrscheinlich ist, da nfs4 beim Mounten explizit ausgewählt werden muss). Dort gibt es aber einen Dämon, der die Nutzer umschreibt (Name müsste ich morgen nachgucken). Der ist nur für nobody/nogroup konfiguriert.
Es gibt einen ID-Mapper -- gucke doch mal auf dem Server nach, wem die Files gehören nach dem Anlegen, wo Dein Client „nobody:nobody“ sagt.
Eine andere Alternative wären die Sicherheitseinstellungen, obwohl SELinux anscheinend gar nicht aktiviert ist.
Hm, das glaube ich auch eher nicht.
Hallo Uwe ;-)
Am Freitag, 5. März 2010 schrieb Uwe Beger:
Anderer Ansatz für Dein eigentliches Problem: rsync
Geht leider nur teilweise, weil ein Buildskript immer wieder Dateien schreiben muss, deren Berechtigungen und Nutzer nicht verloren gehen sollen. Für den initialen Transfer sicher eine Lösung.
Danke Uwe
Am Freitag, 5. März 2010 schrieb Uwe Koloska:
Hallo Uwe ;-)
Am Freitag, 5. März 2010 schrieb Uwe Beger:
Anderer Ansatz für Dein eigentliches Problem: rsync
Geht leider nur teilweise, weil ein Buildskript immer wieder Dateien schreiben muss, deren Berechtigungen und Nutzer nicht verloren gehen sollen. Für den initialen Transfer sicher eine Lösung.
man rsync [...] -a, --archive archive mode .... [...]
Die UID, Zugriffsrechte und Zeitstempel bleiben erhalten. Das sollte doch reichen? Oder übersehe ich etwas?
Jens
Hallo Jens,
Am Samstag 06 März 2010 schrieb Jens Weiße:
Geht leider nur teilweise, weil ein Buildskript immer wieder Dateien schreiben muss, deren Berechtigungen und Nutzer nicht verloren gehen sollen. Für den initialen Transfer sicher eine Lösung.
man rsync [...] -a, --archive archive mode .... [...]
Die UID, Zugriffsrechte und Zeitstempel bleiben erhalten. Das sollte doch reichen? Oder übersehe ich etwas?
Nur, dass ich das Buildscript nicht ändern kann und deshalb einen zusätzlichen Schritt unabhängig von dem Buildscript machen muss. Ansonsten ist das im Moment meine Zwischenlösung um überhaupt arbeiten zu können.
Trotzdem möchte ich gerne wissen, wer für den Squash der Namen verantwortlich ist. Nur noch mal zur Erinnerung: von openSUSE aus funktioniert alles wie erwartet -- es muss also irgendwie an Fedora liegen.
Danke Uwe
Hallo,
da ich seit längerem Fedora (mit Erfolg) nutze und mir soeben ein dickes Buch dazu gekauft habe, hier ein Zitat zu NFS-Optionen in Fedora:
anonuid=un and anongid=gn Set the UID or the GID of the anonymous account to und or gn, respectively. NFS uses these accounts when it does not recognize an incoming UID or GID and when instructed to do so by root_squash or all_squash.
Du hast noch nichts von NIS gesagt, eventuell ist die UID von SuSE auf dem Fedora überhaupt nicht bekannt oder umgekehrt. Oder verwendest Du NFS4 (auf Fedora inzwischen default), dann geht die ganze Sache sowieso etwas anders...
Gruß Jörg
Am 06.03.2010 10:00, schrieb Uwe Koloska:
Hallo Jens,
Am Samstag 06 März 2010 schrieb Jens Weiße:
Geht leider nur teilweise, weil ein Buildskript immer wieder Dateien schreiben muss, deren Berechtigungen und Nutzer nicht verloren gehen sollen. Für den initialen Transfer sicher eine Lösung.
man rsync [...] -a, --archive archive mode .... [...]
Die UID, Zugriffsrechte und Zeitstempel bleiben erhalten. Das sollte doch reichen? Oder übersehe ich etwas?
Nur, dass ich das Buildscript nicht ändern kann und deshalb einen zusätzlichen Schritt unabhängig von dem Buildscript machen muss. Ansonsten ist das im Moment meine Zwischenlösung um überhaupt arbeiten zu können.
Trotzdem möchte ich gerne wissen, wer für den Squash der Namen verantwortlich ist. Nur noch mal zur Erinnerung: von openSUSE aus funktioniert alles wie erwartet -- es muss also irgendwie an Fedora liegen.
Danke Uwe
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Hallo Jörg,
Am Samstag 06 März 2010 schrieb Joerg Bergmann:
anonuid=un and anongid=gn Set the UID or the GID of the anonymous account to und or gn, respectively. NFS uses these accounts when it does not recognize an incoming UID or GID and when instructed to do so by root_squash or all_squash.
Das hilft leider nicht weiter, denn das setzt voraus, dass die squash Funktionen funktionieren. Außerdem ist das eine Option für den Server.
Der Teil ".. when it does not recognize an incoming UID or GID .." gilt entweder nur für den NFS-Server von Fedora (oder er ist falsch). Ich kann auf unserem Server ohne Probleme Dateien als Nutzer anlegen, die es auf dem Server nicht gibt. 'ls' zeigt dann statt dem Namen die UID an.
Du hast noch nichts von NIS gesagt, eventuell ist die UID von SuSE auf dem Fedora überhaupt nicht bekannt oder umgekehrt.
Zumindest bei Verbindung mit Debian 4 oder openSUSE spielt es keine Rolle, ob die UID auf dem Server existiert. Die UID wird genauso gesetzt, wie der Client es angibt.
Oder verwendest Du NFS4 (auf Fedora inzwischen default), dann geht die ganze Sache sowieso etwas anders...
Nein, noch kein NFS4 und ich hoffe, dass der Client nicht nfs4 benutzt, wenn er sich mit einem nfs3 Server verbindet. Ich hatte auch schon überlegt, ob der zu nfs4 gehörende idmapd vielleicht die Probleme verursacht. Aber es gibt keine Veränderung, wenn ich den ausschaltet ...
Hast du vielleicht in deinem dicken Buch eine Option für den NFS-Clienten gefunden, die ihn dazu bringt, seine Anfragen an den Server über einen sicheren Port zu stellen?
Unter BSD gibt es dafür die Option: -P Use a reserved socket port number. This flag is obsolete, and only retained for compatibility reasons. Reserved port numbers are used by default now. This is useful for mounting servers that require clients to use a reserved port number on the mis- taken belief that this makes NFS more secure. (For the rare case where the client has a trusted root account but untrustworthy users and the network cables are in secure areas this does help, but for normal desktop clients this does not apply.)
Für Fedora (und auch die anderen Systeme, die aber standardmäßig einen sicheren (oder reservierten) Port benutzen) habe ich etwas ähnliches aber nicht gefunden.
Danke fürs Mitdenken Uwe
Hallo Heiko,
Am Donnerstag, 4. März 2010 schrieb Heiko Schlittermann:
-> ein besserer Test wäre hier „mkdir test“, da gäbe es deutlichere Anzeichen bei Mißerfolg.
Was gibt es denn da für deutlichere Anzeichen?
Wenn das Objekt schon vorhanden ist, mault es. Und wenn's geht, kannst Du bedenkenlos das leere Verzeichnis wieder löschen. Wenn Du das mit touch machst auf eine schon vorhandene (aber wichtige) Datei, wäre das böse.
Ich habe extra ein Verzeichnis für diesen Test angelegt. Denn damit nobody überhaupt schreiben darf braucht das Verzeichnis ja alle Freiheiten.
- Was macht ein „mkdir /tmp/test“ als der selbe Nutzr, der „mkdir /mnt/server/tmp/test“ macht?
?? Wo soll ich den ersten Befehl ausführen?
Auf dem Client. Einfach ums zu sehen, wer Du bist. (id sollte es auch tun, aber man weiß ja nie…)
Ahh, das habe ich natürlich überprüft.
Ich kann mir eigentlich nur vorstellen, dass der NFS Client von Fedora 10 schon einige NFS4 Eigenschaften nutzt (was unwahrscheinlich ist, da nfs4 beim Mounten explizit ausgewählt werden muss). Dort gibt es aber einen Dämon, der die Nutzer umschreibt (Name müsste ich morgen nachgucken). Der ist nur für nobody/nogroup konfiguriert.
Es gibt einen ID-Mapper -- gucke doch mal auf dem Server nach, wem die Files gehören nach dem Anlegen, wo Dein Client „nobody:nobody“ sagt.
Nutzer und Gruppe habe ich natürlich auf beiden Seiten überprüft und beidemal nobody:nogroup gefunden.
idmapd ist mit an Sicherheit grenzender Wahrscheinlichkeit nicht das Problem: Ich habe ihn ausgeschaltet und der normale Nutzer wurde wieder auf nobody gemapped.
Übrigens passiert das Mapping nur beim Anlegen von Dateien. Schon vorhandene Dateien werden auf dem Clienten mit ihren korrekten UIDs angezeigt ...
Eine andere Alternative wären die Sicherheitseinstellungen, obwohl SELinux anscheinend gar nicht aktiviert ist.
Hm, das glaube ich auch eher nicht.
Ich weiß es jetzt: SElinux ist deaktiviert.
Mist, jetzt gehen mir langsam die Ideen aus. Eine hätte ich noch: Kann es sein, dass das Mapping vom Debian Server gemacht wird, wenn die nfs-Verbindung über "unsichere" Ports reinkommt?
Zum Testen würden zwei Informationen weiterhelfen: - kann ich dem mount von openSUSE sagen, dass es unsichere Ports benutzen soll? - kann ich dem mount von Fedora sagen, dass es sichere Ports benutzen soll?
Gruß Uwe
Hallo Uwe,
Uwe Koloska koloska@voiceinterconnect.de (Fr 05 Mär 2010 10:32:30 CET): (…)
Mist, jetzt gehen mir langsam die Ideen aus. Eine hätte ich noch: Kann es sein, dass das Mapping vom Debian Server gemacht wird, wenn die nfs-Verbindung über "unsichere" Ports reinkommt?
Zum Testen würden zwei Informationen weiterhelfen:
- kann ich dem mount von openSUSE sagen, dass es unsichere Ports benutzen
soll?
- kann ich dem mount von Fedora sagen, dass es sichere Ports benutzen soll?
Das könnte man mit SNAT in der OUTPUT NAT-Chain hinbekommen… Die in Frage kommenden Ports müsste man mit portmap -p <server> rausbekommen.
Hallo Heiko,
Am Samstag 06 März 2010 schrieb Heiko Schlittermann:
Das könnte man mit SNAT in der OUTPUT NAT-Chain hinbekommen… Die in Frage kommenden Ports müsste man mit portmap -p <server> rausbekommen.
Es geht nicht um die Ports, die auf dem NFS-Server benutzt werden, sondern die, die vom Client für die Anfrage benutzt werden. Kann ich die auch umbiegen?
Gruß Uwe
Uwe Koloska ml@koloro.de (Sa 06 Mär 2010 21:36:45 CET):
Hallo Heiko,
Am Samstag 06 März 2010 schrieb Heiko Schlittermann:
Das könnte man mit SNAT in der OUTPUT NAT-Chain hinbekommen… Die in Frage kommenden Ports müsste man mit portmap -p <server> rausbekommen.
… nicht OUTPUT sondern POSTROUTING
Es geht nicht um die Ports, die auf dem NFS-Server benutzt werden, sondern die, die vom Client für die Anfrage benutzt werden. Kann ich die auch umbiegen?
Ja, ich meinte es ja auch nur, damit Du etwas hast, wonach Du die Regeln aufstellen kannst, etwa so:
for dport in <liste der udp/tcp ports aus rpcinfo -p> do iptables -t nat -A POSTROUTING -p <proto> --dport $dport -j MASQUERADE --to-ports 1-1024 done
Möglicherweise genügt das für den NFS-Port (2049 meist).
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Jens Weiße -
Joerg Bergmann -
Uwe Beger -
Uwe Koloska -
Uwe Koloska