Re: Fedora verändert uid bei nfs Zugriff
Anderer Ansatz für Dein eigentliches Problem: rsync Gruss Uwe [...] ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Fedora verändert uid bei nfs Zugriff
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 -- Dipl.-Ing. Uwe Koloska Leiter Softwareentwicklung voice INTER connect GmbH Tel +351 481 088 3 Ammonstraße 35Fax +351 438 399 25 01067 Dresden - Germany www.voiceinterconnect.de Geschäftsführung: Dr.-Ing. Diane Hirschfeld, Ludwig Linkenheil Eingetragen im Handelsregister: Amtsgericht Dresden HRB 19466 *** Besuchen Sie uns auf der embedded world 2010 *** vom 2.-4.3. in Nürnberg, Halle 11, Stand 418 voiceINTERconnect www.voiceinterconnect.de ... smart speech applications from Germany ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Fedora verändert uid bei nfs Zugriff
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. 1) 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? 2) 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 ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Fedora verändert uid bei nfs Zugriff
Uwe Koloska m...@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. 2) 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. -- Heiko signature.asc Description: Digital signature ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
