Hi,
Aber die normalen begrenzten User/Groups ohne Login (meist wwwrun/wwwrun o.ä.) sind tatsächlich zu empfehlen. Ist dann zumindest etwas aufgeräumter.
Es geht nicht ums Aufgeräumtsein, es geht um handfeste Sicherheitsüberlegungen: Wenn ein Angreifer einen Webservice erfolgreich angreift, hat er die Zugriffsrechte des Benutzeraccounts, unter dem der Webservice läuft. Würde es also nur einen einzigen Netz-Account geben, der für HTTP und FTP gleichzeitig genutzt wird, so könnte ein Angreifer z.B. via FTP eindringen und auch den HTTP-Server manipulieren - sind ja dieselben Accounts, also sind auch alle Dateien, die dieser Account lesen oder schreiben darf, zugriffsfähig.
Ja, das mag stimmen, ich bin da vielleicht etwas zu paranoid: für mich ist bei einem erfolgreichem Angriff jedweder Art stets anzunehmen, das das gesamte System beschädigt ist und dementsprechend zu handeln. Dementsprechend bringt eine Trennung nicht sonderlich viel. Es sollte pro Box ja normalerweise auch nur ein einziger Dienst laufen, aber das ist ja aus einsehbaren Gründen nur selten möglich, mindestens ein SSHD o.ä. läuft ja immer mit.
Achso: ein user ist wirklich nicht per se nötig, das funktioniert alles auch ganz ohne!
Ein User ist immer zwingend nötig, ohne mindestens einen User läuft Linux nämlich nicht.
Da muß ich Dich enttäuschen, Linux läuft auch ohne User. Dann läuft aber maximal ein Programm. Wird im Embeded-Bereich öfter mal genutzt. Da aber dadurch kein Remotezugriff möglich ist (der würde ja ein paar Programme mehr benötigen), könnte man das Dingen natürlich nur ein- und ausschalten, mehr nicht. Reicht aber auch in vielen Fällen, wenn TRON nicht reicht und QNX o.ä. zu teuer ist.
Aber es versteht sich irgendwie von selbst, dass man Webservices nicht als root laufen läßt - außer man möchte eine adrenalinerhöhende Extremsportart betreiben, ohne zuviele Kalorien zu verbrennen.
_Rein theoretisch_ ginge das, aber darauf würde ich mich freiwillig bestimmt nicht einlassen, wie schnell wird da 'was vergessen ;-)
Hätte dann aber auch die gleichen Nachteile, wie ganz ohne User: da keine Shell da sein darf, auch kein Remotezugriff vorhanden ist.
Wo der Unterschied zwischen hardlinken und hochladen so rein von der Vorgehensweise ist, entzieht sich etwas meinem [...]
Softlinks notwendig), oder per Shellskript mal eben einen Upload auf einen externen Server zu starten.
Das war doch mein Reden, aber mir glaubt ja keiner! ;-)
Dafür gibt es spezielle Services wie CVS u.ä., die das wunderbar unterstützen. Dann muß sich der Kollege ebenfalls nicht alles runterladen sondern kann sich mit dem Diff begnügen.
Ich würde dafür nicht unbedingt CVS nehmen. Dieses System hat mit großen Dateien so seine Probleme, insbesondere mit Binärdateien.
Was denn, immer noch?
Naja, meine größten Dateien sind eh nur C-Header mit vielen ifdef's, da kommen vielleicht mal 50 kib zusammen, mehr nicht ;-)
DynDNS ist mittlerweile auch deshalb schwieriger geworden, weil nicht nur alle 24h die IP wechseln kann, sondern auch zwischendurch. Je nach Anbieter und Tageszeit kann das auch häufiger passieren. Beim Surfen nicht weiter lästig, für einen DynDNS-Server Benutzer hingegen ziemlich.
Das Wechselintervall ist hinsichtlich der lästigen Erreichbarkeitsunterbrechung irrelevant. Im Zweifel ist der eigene Besuch exakt genau dann betroffen, wenn man gerade auf die interessanteste Webseite gehen wollte.
Davon ist auszugehen, ja. Aber einmal ist ja bekannt, nur wenn das mehrmals in kurzer Zeit vorkommt, ist das lästiger, als nur einmal. Der normale Windowsuser verzeiht nunmal, aus welchen Gründen auch immer, kurzfristige Störungen, fühlt sich mittlerweile bei Wiederholungen aber dann doch genervt.
Ebenso, wenn man sich mit Passwortabfrage auf dem DynDNS-Server anmeldet: Die Passworte gehen an den falschen Server, was ist, wenn der das munter mitschreibt und gegen einen verwendet?
Dagegen gäbe es kryptographische Mittel und Wege, aber die sind kaum einem Fortgeschrittenem, geschweige denn einem Anfänger zuzumuten. Zumal sie auch noch zum Teil auf der unkontrollierbaren Clientseite passieren müssen.
so short
Christoph Zurnieden