Hallo, * Am 16.07.2002 postete Thomas Michalka:
Alex Klein wrote:
* Am 14.07.2002 postete Thomas Michalka:
folgendes Verhalten beim Start des kernel-based nfsserver unter SuSE-7.3 irritiert mich auf's äußerste:
helios:/# /usr/sbin/rcnfsserver restart Shutting down kernel based NFS server done Starting kernel based NFS serverterra.michalka.home:/: Invalid argument done
Diese Meldung bekomme ich, seitdem ich in den Security-Settings in YaST2 die File-Permissions von "Easy" auf "Secure" gesetzt habe.
(Da gibt es übrigens einen Fehler: wenn man YaST2 beendet hat und wieder startet, dann ist die File-Permissions-Anzeige wieder auf "Easy" - sind es die File-Permissions selber auch?)
Keine Ahnung. Wer traut schon YaST2?
Nun, es ist grundsätzlich so, wie wenn ich einen Kühlschrank kaufe - ich erwarte, daß er ordnunggemäß kühlt, nicht wahr?
Und? Dein YaST2 läuft auch und verändert auch die Config files. Du erwartest von Deinem Kühlschrank auch nicht, daß Bier drin liegt.
SuSE verkauft mir mit der Distribution YaST2 (u.v.a.m) - ich erwarte, daß YaST2 die Aufgaben, die SuSE eingebaut hat, ordnungsgemäß erfüllt.
Das Ding heißt aber SuSE-Linux und nicht SuSE-YaST2.
Überspitzt gesagt bräuchte ich mir für 89 Euro keine SuSE-Distribution kaufen, wenn ich immer mit Fehlern in der SuSE-eigenen Software rechnen müßte, die SuSE durch einfaches Selberausprobieren (Testen genannt) leicht selbst gefunden hätte.
Wenn eine bestimmte Software features nicht vorsieht, dann ist es nicht Aufgabe des Admin-Tools, das festzustellen. Nett, wenn es das Tool macht, aber daß es nicht geht, das sollte schon dem Admin klar sein.
Wenn ich meinen Kunden einen Software liefere, wo noch Fehler drin sind, dann habe ich 24 Monate (nach der neuen Regelung) lang die kostenlose Beseitigung dieser Fehler zu gewährleisten.
Quatsch. Hast Du eigentlich Dein YaST2 schonmal aktualisiert? Außerdem macht YaST2 keinen Fehler. Es konfiguriert etwas, das nicht geht. Dafür haftet SuSE nicht. Die Gewährleistung hast Du auf das Produkt YaST2. Und das erstellt das Configfile nach Deinen Wünschen. YaST2 kann nicht den Export festlegen, der ungültig ist.
Davor hatte der nfsserver kein Problem mit dem Export des Root-File-Systems. Meine /etc/exports sieht so aus:
/ terra(rw,no_root_squash)
^ Ich tippe mal darauf, daß es dem nfsserver gar nicht paßt, daß Du secure permissions nutzen willst, dabei aber dann doch gleich mal das Rootfilesystem freigeben willst.
Ich habe es auch schon mit der insecure-Option probiert - mit dem gleichen Ergebnis.
========================== NFS-HOWTO ===================================== 6.5. Summary If you use the hosts.allow, hosts.deny, root_squash, nosuid and privileged port features in the portmapper/nfs software you avoid many of the presently known bugs in nfs and can almost feel secure about that at least. But still, after all that: When an intruder has access to your network, s/he can make strange commands appear in your .forward or read your mail when /home or /var /mail is NFS exported. For the same reason, you should never access your PGP private key over nfs. Or at least you should know the risk involved. And now you know a bit of it. ========================================================================== Zu Deinem Problem: ========================== NFS-HOWTO ===================================== A few cautions are in order about what cannot (or should not) be exported. First, if a directory is exported, its parent and child directories cannot be exported if they are in the same filesystem. However, exporting both should not be necessary because listing the parent directory in the /etc/exports file will cause all underlying directories within that file system to be exported. ==========================================================================
Ehrlich gesagt halte ich es persönlich auch nicht gerade für sinnvoll. Deine /etc/exports zeigt ja gerade, daß Du Dir um Sicherheit recht wenig Gedanken machst (no_root_squash, rw)
Das würde ich so nicht sagen. Erstens handelt es sich dabei um zwei Rechner, die ich, und nur ich unter meiner Fuchtel habe. Zweitens ist dieser Export nur ein Workaround zum spiegeln von einigen wertvollen Daten, bis wieder ein vernünftiger Backup geht. Drittens befindet sich mein LAN hinter einer Firewall (obwohl ich nicht paranoid bin). Viertens wird keines der NFS-Shares automatisch gemountet und ich bin auf allen Rechnern der SU und weiß, was ich tue.
Fünftens kann jeder, der root-Rechte auf dem anderen Rechner erlangt auch root-Rechte auf diesem System bekommen: This can have serious security implications, although it may be necessary if you want to perform any administrative work on the client machine that involves the exported directories. You should not specify this option without a good reason.
Weil es zwar praktisch ist, aber doch ein erhebliches Risiko darstellt.
Bei mir nicht - siehe oben. Es könnte schon sein, daß SuSE unter Paranoia leidet - wieso sind sonst derart viele Netzwerkhürden eingebaut. Beispiele zu nennen wäre jetzt müßig, aber müssen denn vor lauter Sicherheit sogar Dinge unbenutzbar sein, die SuSE sogar selber im Netzwerkhandbuch "anpreist" (aber die Schritte dazu nicht vollständig nennt)?
Ich denke nicht, daß das auf SuSEs Mist gewachsen ist, sondern einfach zur UNIX/Linux Philosophie gehört. Unter Windows ist man sich der Lücken eben einfach nicht bewußt genug. Und bei Dir ist es ein Risiko, auch wenn Du es anders einstufst.
Übrigens gibt's keine Meldung obiger Art, wenn man den besagten Export auskommentiert, d.h. alle anderen funktionieren.
Habe ich irgendein Security-Setting diesbezüglich übersehen? Falls ja, dann ist es jedenfalls kein Standard nach einer frischen Installation, weil der /-Export ja zunächst funktioniert hat.
Na siehst Du. Entweder keine Security und / exportiert, oder eben kein /-Export, dafür die _Möglichkeit_ es relativ sicher zu gestalten.
Bitte lies genau: die anderen Partitionen kann ich schon exportieren (z.B. /var, worin sich u.a. die Benutzer-Mails befinden) - warum sollte das kein Sicherheitsrisiko darstellen?
Lesen bildet ungemein. Im NFS-HOWTO steht auch drin, daß es bedenklich ist. Und ich habe eben jetzt so mal mehr Vertrauen in die NFS-Entwickler, wenn es schon um NFS geht. Ich finde es zudem aber auch mehr als einleuchtend. Sind Deine anderen Exports alles eigene Partitionen? Wenn nein, dann hätten wir wohl schon die Lösung.
Tut mir leid, daß das nicht sehr hilfreich für mich ist, denn es ging mir eigentlich um die Frage, warum
"terra.michalka.home:/"
ein "Invalid Argument" sein soll. Für mich hört sich das - wenn ich es genau lese - nicht gerade wie eine Erlaubnisverweigerung im Sinne einer Sicherheitseinstellung an, sondern eher an, wie - naja, was weiß ich :-? Ein syntaktisches Problem ist es wohl auch nicht, denn in diesem Fall erhält man eine detailierte Meldung, was im exports-Eintrag falsch ist.
Geht der Export allein?
Es kann viele gute Gründe geben, die Root-Partition zumindest temporär zu exportieren, und ich finde über die evtl. Unzulässigkeit, das zu tun, bisher keinerlei Hinweise. Übrigens kann man durchaus auch "sicher" exportieren, z.B. mit read_only.
Lesen ist auch ein Sicherheitsrisiko. Für Dich evtl. nicht und für jemanden, der Bedienungsanleitungen für frei erwerbbare Sachen hat sicherlich auch nicht. Aber es _kann_ ein Sicherheitsrisiko sein.
Nun ja, es wäre nett, wenn sich hier gelegentlich auch mal jemand von SuSE melden könnte, denn das Problem trat, wie gesagt, unmittelbar nach einer Umstellung der file permissions mit YaST2 auf und läßt sich durch eine Rückumstellung nicht beheben.
Hast Du schonmal die sdb gefragt? Beste Grüße Alex -- Das ist keine Sigg, Zum Kuckuck noch mal! Und wenn du eine daraus machst, so ist das deine Schuld. [WoKo zu Michael Hoffmann in dag°]