KeyHelp Community

Hallo,

wenn man einen neuen Benutzer anlegt, wird derzeit dessen Home-Verzeichnis wie folgt erstellt:
Das hat meines Erachtens jedoch zwei Nachteile, zumindest wenn man seinen Kunden SSH-Zugang erlauben will oder muss:

1. Der User hat selbst kein Schreibrecht auf sein Home-Verzeichnis. Das führt bei einer Reihe an Befehlen (z.B. nano, mc, crontab) zu Fehler- oder Warnmeldungen, weil die benötigten Konfigurationsdateien in ~/.config oder ~/.cache usw. nicht angelegt werden können.

2. SSH-User können sich den Inhalt anderer Home-Verzeichnisse ansehen. Sie kommen zwar nicht weiter in die Unterverzeichnisse (www usw.), aber dennoch, das ist etwas unschön finde ich.

Ich habe nun mal testweise die Dateirechte wie folgt angepasst:
Nachteil hier bei ist natürlich, dass der Kunde wichtige Verzeichnisse (z.B. www) löschen kann. Aber hier sehe ich den Kunden in Eigenverantwortung, wenn er denn SSH-Zugang haben will.

Spontan kann ich keine negativen Auswirkungen im Betrieb feststellen, Apache liefert die Seite aus, PHP funktioniert, Logs werden geschrieben, FTP-Zugang läuft.

Meine Fragen wären nun:

1. Ich bin mir unsicher, ob nicht hinter den Kulissen in keyhelp noch irgend etwas abläuft, was durch diese Rechteänderung gestört werden könnte. Vielleicht kann einer der Entwickler dazu etwas sagen?

2. Falls es keine Probleme damit gibt, sollte man evtl. die Rechte künftig wie von mir vorgeschlagen vergeben? Was meint ihr?

Bin gespannt auf euer Feedback


Viele Grüße,
Lars

2. SSH-User können sich den Inhalt anderer Home-Verzeichnisse ansehen. Sie kommen zwar nicht weiter in die Unterverzeichnisse (www usw.), aber dennoch, das ist etwas unschön finde ich.

Mir ist so, als wenn dafür mal quota / chroot angedacht waren. Aber warten wir mal die Antwort eines Admin ab,

nikko wrote: ↑Thu 28. Sep 2017, 10:00 Mir ist so, als wenn dafür mal quota / chroot angedacht waren. Aber warten wir mal die Antwort eines Admin ab,

Stimmt, das ist wohl in Planung, siehe viewtopic.php?f=2&t=61&p=226&hilit=chroot#p226. Ich hoffe aber, dass das optional sein wird. Meine Erfahrungen mit chrooted Umgebungen bei diversen Hostern waren sehr gemischt. Vieles lief dort einfach nicht richtig, weil irgend etwas fehlte usw. Aber vielleicht ist das heutzutage auch gar kein Problem mehr, meine Erfahrungen dazu liegen bereits einige Jahre zurück...

l_fish wrote: ↑Thu 28. Sep 2017, 08:47Nachteil hier bei ist natürlich, dass der Kunde wichtige Verzeichnisse (z.B. www) löschen kann. Aber hier sehe ich den Kunden in Eigenverantwortung, wenn er denn SSH-Zugang haben will.

An dem Punkt bekomme ich ein ungutes Gefühl.
IMHO muß das Ganze DAU-tauglich sein. Man darf von einem Kunden keine Eigenverantwortung erwarten.
Wenn dann tatsächlich der Webroot gelöscht wurde, ist das Geschrei groß und nach Murphy's Gesetz hat der User, der seinen Webroot löscht, dann auch zu 99,9% kein aktuelles Backup davon.
Wenn dann auch noch der Folder für die Logfiles weg wäre, könnte möglicherweise sogar der Logger aus dem Tritt kommen.

Nachtrag:
Eventuell kann man hier mit ACL noch Feintuning betreiben, um das gewünschte Ergebnis zu erreichen.
Aber bevor ich jetzt hier völligen Blödsinn rede, muß ich mich heute abend nochmal in das Thema reinlesen. Ist schon zu lange her, daß ich aktiv mit ACL gearbeitet habe.

Hallo,

exakt der Grund, das der Kunde ansonsten www/ löschen könnte ist der Grund warum die Dateirechte für das $HOME so sind wie diese aktuell gesetzt sind. Sofern der Folder für Logfiles fehlen würde, würde bei einem Restart des Apaches dieser garnicht mehr starten (fehlende Logfiles würde er erstellen, fehlende Logordner sind fatal).
Erfahrene Benutzer, welche entsprechende Rechte in Ihrem $HOME möchten und sich dessen bewusst sind sollten hier nicht vor dem Problem stehen das Dateirecht für den fraglichen Nutzer manuell anzupassen.

Bezüglich CHROOT:
Dies steht wie richtig angemerkt wurde auf unserer ToDo Liste, und wäre dann optional wählbar (angedachte Optionen: SSH-normal (wie jetzt), SSH-chrooted und SFTP-only(chrooted))

Martin wrote: ↑Thu 28. Sep 2017, 23:13Sofern der Folder für Logfiles fehlen würde, würde bei einem Restart des Apaches dieser garnicht mehr starten (fehlende Logfiles würde er erstellen, fehlende Logordner sind fatal).

Ohh okay, wieder was Interessantes dazugelernt.
Ich hab so eine Situation noch nie gehabt bzw. provoziert, daher auch meine Vermutung, daß der Logger straucheln könnte...Aber daß der Indianer dann gleich den Dienst verweigert, hätte ich jetzt nicht unbedingt vermutet.
Danke für diese Nachhilfe.

Hallo,

vielen Dank für die Rückmeldungen! Insbesondere das Argument mit den fehlenden Logordnern ist natürlich berechtigt. Ich habe daher nun folgende Lösung gewählt:

Beim Anpassen der Rechte erzeuge ich in jedem der vorhandenen Standard-Verzechnisse (cgi-bin, files, logs, tmp, www) als root eine Datei .protected (mit dem erklärenden Inhalt "Dieses Verzeichnis darf nicht gelöscht werden.") und setze für diese chattr +i .protected. Damit lassen sich die Verzeichnisse nicht mehr löschen. Ist vielleicht nicht die schönste Lösung, aber für meinen Zweck erst einmal ausreichend

Viele Grüße,
Lars