Hallo, 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?) Davor hatte der nfsserver kein Problem mit dem Export des Root-File-Systems. Meine /etc/exports sieht so aus: / \ terra(rw,no_root_squash) /usr \ terra(rw,no_root_squash) /opt \ terra(rw,no_root_squash) /tmp \ terra(rw,no_root_squash) /boot \ terra(rw,no_root_squash) /home \ terra(rw,no_root_squash) /var \ terra(rw,no_root_squash) /misc/more \ terra(rw,no_root_squash) /misc/linux_any \ terra(rw,no_root_squash) /misc/win_c \ terra(rw,no_root_squash) /misc/win_d \ terra(rw,no_root_squash) So wird sie von YaST2 erzeugt, wenn man dort die zu exportierenden Dateisysteme bzw. Verzeichnisse festlegt. Wieso sollte es nicht möglich sein, das /-Verzeichnis zu exportieren? Ü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. Danke für die Hilfe! Gruß, Thomas
Hallo, * Am 14.07.2002 postete Thomas Michalka:
Hallo,
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?)
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. Ehrlich gesagt halte ich es
Keine Ahnung. Wer traut schon YaST2? 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)
/usr \ terra(rw,no_root_squash) /opt \ terra(rw,no_root_squash) /tmp \ terra(rw,no_root_squash) /boot \ terra(rw,no_root_squash) /home \ terra(rw,no_root_squash) /var \ terra(rw,no_root_squash) /misc/more \ terra(rw,no_root_squash) /misc/linux_any \ terra(rw,no_root_squash) /misc/win_c \ terra(rw,no_root_squash) /misc/win_d \ terra(rw,no_root_squash)
So wird sie von YaST2 erzeugt, wenn man dort die zu exportierenden Dateisysteme bzw. Verzeichnisse festlegt.
Wieso sollte es nicht möglich sein, das /-Verzeichnis zu exportieren?
Weil es zwar praktisch ist, aber doch ein erhebliches Risiko darstellt.
Ü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. Beste Grüße Alex -- "But what...is it good for?" --Engineer at the Advanced Computing Systems Division of IBM commenting on the microchip, 1968.
Alex Klein wrote:
Hallo,
* Am 14.07.2002 postete Thomas Michalka:
Hallo,
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? SuSE verkauft mir mit der Distribution YaST2 (u.v.a.m) - ich erwarte, daß YaST2 die Aufgaben, die SuSE eingebaut hat, ordnungsgemäß erfüllt. Ü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 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.
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.
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. [...]
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)?
Ü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? 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. 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. 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. Schöne Grüße Thomas
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°]
Hallo, erstmal danke für Deine ausführliche Antwort! Darauf muß ich nun wieder antworten, aber damit der Body nicht zu riesig wird, muß ich wohl einiges kürzen, was meine Anwort für sich genommen vielleicht nicht verständlicher macht. Aber wen's interessert kann ja den Thread noch von oben her durchgehen. Alex Klein wrote:
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.
Schön, aber daß YaST2 nach erneutem Start behauptet, die File-Permissions seien immer noch auf "Easy", obwohl ich sie vorher auf "Secure" verändert hatte, ist doch wohl eindeutig ein Fehler in der Software, den man durch bloßes Ausprobieren (von Testen will ich hier gar nicht reden) bei SuSE hätte finden können. Meine Zeit ist einfach zu teuer, um nachzuforschen, ob YaST2 die Permissions wirklich nicht verändert hat oder nur die Anzeige im YaST-Modul falsch ist.
Du erwartest von Deinem Kühlschrank auch nicht, daß Bier drin liegt.
Wenn es so wäre, dann lebte ich im Schlaraffenland :-) Aber ich erwarte von YaST2 auch nicht, daß es die Dateien /etc/permisssions.* selber aus dem Nichts erschafft, sonder nur, daß es die Permissions daraus korrekt liest und danach einstellt, und die schlußendlich korrekt anzeigt.
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.
Noch besser, dann hätte SuSE juristisch sogar die Verpflichtung, für alles was mitgeliefert wird, eine Gewährleistung auf bestimmungsgemäße Funktion über 24 Monate zu übernehmen. ;-) Hurra, wir Käufer sind echt fein raus! :-) Also, mal ernst, ich erwarte nicht, daß SuSE jedes einzelne, der über 4000 Software-Pakete austestet - das wäre echt zuviel verlangt. Aber daß SuSE ihre selbst verbrochene Software testet (Gut- und Schlechtfälle), kann man mit Fug und Recht erwarten! [ ... ]
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.
Du hast mich offenbar falsch verstanden. Falls man die Root-Partition tatsächlich nicht mehr exportieren können sollte (was ich nicht glaube, weil ich es mit der 7.3 schon gemacht habe), dann erwarte ich natürlich *nicht*, daß YaST diese Erkenntnis eingebaut hat! Der Fehler, den ich oben moniert habe, ist YaST2-intern und hat als solcher nichts mit NFS zu tun.
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.
Willst Du besser wissen, welche rechtlichen Verpflichtungen *ich* habe?
Hast Du eigentlich Dein YaST2 schonmal aktualisiert?
Gerade erst wieder, aber dieser Fehler (s.o.) ist immer noch drin.
Außerdem macht YaST2 keinen Fehler. Es konfiguriert etwas, das nicht geht. Dafür haftet SuSE nicht.
Diese Aussage hier beruht auf Deinem Mißverständnis meiner Fehlerschilderung (s.o.) - vielleicht hätte ich mein Problem mit NFS nicht mit meiner Nebenbemerkung zu diesem Fehler garnieren sollen :-\
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.
Dann verstehen wir uns ja jetzt!
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 ===================================== [ ... ] ==========================================================================
Danke, hab' ich auch gelesen. Wenn ich aber ständig Furcht vor Eindringlingen in mein LAN hätte, dann würde ich wirklich unter Paranoia leiden. Das Ziel muß dcch sein, Eindringlinge möglichst schon an der Firewall aufzuhalten. Sonst müßte ich in meiner Wohnung jedes Zimmer mit Sicherheitsschlössern ausstatten und ständig einen schweren Schlüsselbund mit mir rumschleppen. Wie absurd das ist, sieht man daran, daß mein Vergleich hier insofern hinkt, daß ich eher Zimertüren zumauern müßte, damit ich mein "/home" nicht von zwei verschiedenen Zimmern (Rechner A und B) betreten kann.
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.
==========================================================================
[ ... ]
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.
Danke für Deine Fürsorglichkeit! ;-) [ ... ]
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.
Diese qualitativen Einschätzungen sind mir zu schwammig. Wie hoch ist denn das Risiko, daß jemand über meine Firewall und über Rechner A auch auf Rechner B eindringt? Angenommen, die Wahrscheinlichkeit, daß während eine Online-Zeit jemand meine Firewall überwindet, wäre 1%, und diejenige, daß er wegen NFS-Exports von einem auf den anderen Rechner im LAN (auf dem Firewall-Rechner läuft kein Dienst, außer der Paketfilterung) kommt, wäre 90%, dann wäre die Gesamtwahrscheinlichkeit, daß er die Firewall knackt _UND_ über Rechner A auf Rechner B kommt das Produkt der Wahrscheinlichkeiten, d.h. 0,01 * 0,90 = 0,09, also 0,9%. Betrügen die zweite Wahrscheinlichkeit nur 10 %, dann wäre das Gesamtrisiko zwar nur 0,1%, also um den Faktor 9 geringer, aber der Risikounterschied beträgt nur 0,8%. Soll ich mich deswegen verrückt machen, und auf *temporär_kurzzeitiges* NFS verzichten? Die Wahrscheinlichkeitswerte sind zwar nur angenommen, aber die quantitative Abschätzung zeigt schon ungefähr die "Größenordnung" des Effekts, über den wir diskutieren. [ ... ]
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.
Ja, aber noch mehr das selber Ausprobieren, auch wenn's einem gefährlich vorkommt ;-) Wenn das so mancher früher nicht gewagt hätte, wüßten wir um solche Problematiken heute fast nichts. [ ... ]
Sind Deine anderen Exports alles eigene Partitionen?
Das sind sie, allesamt.
Wenn nein, dann hätten wir wohl schon die Lösung.
Tja, leider ...
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. [ ... ]
Geht der Export allein?
Meinst Du, wenn alle anderen Partions-Exports auskommentiert sind? Ich probiere das morgen aus, für heute ist es mir jetzt schon zu spät. Wenn ich mehr weiß, gebe ich Laut ...
Hast Du schonmal die sdb gefragt?
Ja, aber leider nichts dazu gefunden. Schönen Gruß, Thomas
Sind Deine anderen Exports alles eigene Partitionen?
Das sind sie, allesamt.
Hier habe ich mich geirrt und doch Recht gehabt! Die korrekte Antwort auf die Frage hätte sein müssen: "Das _waren_ sie, allesamt."
Wenn nein, dann hätten wir wohl schon die Lösung.
So ist es, wir haben Sie :-) Eines der unteren Verzeichnisse dienten früher als Mountpoints für Partitionen einer Platte, die nicht mehr in dem Rechner ist und die auch nicht automatisch gemountet wurden, sondern ebenfalls nur temporär zu Backup-Zwecken. Dieses aber war bei mir in Vergessenheit geraten :-\
Geht der Export allein?
Meinst Du, wenn alle anderen Partitions-Exports auskommentiert sind?
Diese Frage hat mich daraufgebracht. Danke für den treffenden Hinweis! Allerdings muß man feststellen, daß die Fehlermeldung des NFS-Servers "terra.michalka.home:/: Invalid Argument." bei so einem Fehler schon extrem unzutreffend/unvollständig ist. Das ungültige Argument konnte höchstens der Mountpoint ohne gemountete Partition sein, nicht aber die Root-Partition, die als solche hätte exportiert werden können. Danke nochmal für die Hilfe, und Dank auch an die anderen, die sich beteiligt haben, wenn auch nicht so treffsicher ;-) Schönen Gruß, Thomas
participants (3)
-
Alex Klein
-
Michael Lootz
-
Thomas Michalka