nicht angemeldet
Moin!
Ja, denn der User "netz" hat hier beides unter sich, das ist tunlichst zu vermeiden. Wenn der User dann sogar noch eine Shell hat ging's wirklich daneben.
Vollkommen richtig. Jeder Webservice sollte seinen eigenen Benutzeraccount erhalten, welcher hinsichtlich seiner Zugriffsrechte so weit wie möglich eingeschränkt ist auf das zum Betrieb notwendige, aber keinesfalls mehr.
Also: Apache kriegt seinen eigenen Benutzer (oft wwwrun oder apache genannt), und FTP kriegt ebenfalls einen eigenen Benutzer (ob man den jetzt ftp nennt, ist wohl eine Geschmacksfrage). Entsprechend sollte jeder dieser Accounts auch eine eigene Gruppe erhalten, in der er und alle anderen Benutzeraccounts, die in dem jeweiligen Bereich Zugriff erhalten sollen, untergebracht werden. Die richtige Account- und Gruppenplanung zusammen mit der entsprechenden Zuweisung der Dateizugehörigkeiten und -rechte ist essentiell für einen sicheren Betrieb.
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.
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. 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.
Wenn ich z.B. jemandem einige Dokumente schickien will, dann hardlinke ich Sie einfach in /etc/public und der kann sich da bedienen.
ansonsten muesste ich das ganze noch auf nen server hochladen und nachher wieder loeschen.
Wo der Unterschied zwischen hardlinken und hochladen so rein von der Vorgehensweise ist, entzieht sich etwas meinem Verständnis. Beides erfordert manuelles Eingreifen, beides kann schiefgehen, bei beidem wird für die Zeit der Datenübertragung die Leitung ausgenutzt. Ist es nun wirklich einfacher, einen Hardlink auf der Festplatte herzustellen (wobei anzumerken ist: Hardlinks funktionieren nur, wenn Quelle und Ziel im selben Filesystem liegen, ansonsten sind Softlinks notwendig), oder per Shellskript mal eben einen Upload auf einen externen Server zu starten.
Letzeres ist jedenfalls wesentlich sicherer, insbesondere wird da die Leitung dann belegt, wenn ICH es will, und nicht, wenn jemand anderes den Downloadversuch startet.
Und vor allem werden aenderungen sofort uebernommen, ich muss nicht nac jeder aenderung den scheiss nochmal hochladen.
rsync wäre die Antwort.
Außerdem besteht ja durchaus die Gefahr, dass du derartig hart verlinkte Dokumente vergißt und später mit Inhalten füllst, die eigentlich doch nicht veröffentlicht werden sollten.
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.
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. DynDNS stört sich da nicht sonderlich dran, solange die IP sich ändert, wird diese Änderung online verfügbar gemacht und fertig.
Genau diese Unterbrechungen sind aber ein handfester Grund, gewisse Webservices eben gerade NICHT auf DynDNS-Servern anzubieten. Denn wenn die eigene IP gerade verlorengegangen ist und an einen anderen Benutzer vergeben wurde, laufen bei dem ja alle neu aufgebauten Verbindungen solange auf, bis das DNS die neue IP verteilt hat. Sowas ist durchaus ein Risiko. Was ist z.B., wenn man einen eigenen Mailserver betreibt - dann landen die eigenen Mails alle in fremden Händen (abgesehen davon: Man betreibt auf dynamischen IPs keine Mailserver, weder für eingehende, aber erst recht nicht für ausgehende Mails - zuviele Viren tun dasselbe, so dass die eigene Mail fast sicher in Spamfiltern hängen bleiben wird). 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?
- Sven Rautenberg