staging.inyokaproject.org

sudo chown $USER:$USER $HOME -R
cd $HOME
find  -type d -exec chmod 755 {} \;
find  -type f -exec chmod 644 {} \;

Im ersten Befehl wird das Homeverzeichnis des aktuellen Benutzers wieder diesem zugewiesen, im Zweiten wechselt man in das Homeverzeichnis, im dritten und vierten Schritt sucht man mittels Shell/find alle Dateien bzw. Verzeichnisse und weist diesen die richtigen Rechte zu.

Das sind nicht die "richtigen" Rechte. Auch wenn das im nächsten Absatz relativiert wird, finde ich den Ansatz falsch, erstmal alles lesbar zu machen und es dann dem Benutzer zu überlassen, einzelne Dateien wieder restriktiver zu behandeln. Damit ist derjenige, der diesen Artikel üebrhaupt braucht, nämlich überfordert, und weil ja "alles funktioniert" bleiben dann Mailpasswörter, etc. für alle lesbar.

Besser wäre imho, erstmal nur die Rechte des Homeverzeichnisses selber zu setzen und dann ein paar Dateien wie .dmrc aufzulisten, die evtl. weitere Rechte benötigen. In den allermeisten Fällen reicht der chown-Befehl sowieso aus, oder das x-Bit im Homeverzeichnis ist gelöscht.

Homeverzeichnis nur für den eigenen Benutzer lesbar

Ich bin immer noch für meinen Vorschlag oder würde sonst vorschlagen, beides alternativ mit Vor- und Nachteilen vorzustellen.

P.S.: Bei mir ist auch die Datei .dmrc mit 0600 abgesichert, ohne dass ich daran je was geändert hätte und ohne dass ich Login-Probleme hätte.

Der Abschnitt Rechte korrigieren finde ich so nicht ganz korrekt.
Der Artikel bezieht sich ja wie es aussieht auf den ersten angelegten Benutzer auf einem System, also der Benutzer der ohne änderungen sudo nutzen kann.
Für einen weiteren Benutzer ist das Nutzen von sudo ohne der Anpassung der Datei /etc/sudoers oder der Gruppenzuordnung nicht möglich.
Ich würde schreiben, das sich dies auf den ersten angelegten Benutzer bezieht.

Wobei der Benutzer auch ohne sudo die Rechte an seinem Homeverzeichnis mittels chown und chmod ändern kann.
Also sudo nicht notwendig ist.

mreczio hat geschrieben:

Für einen weiteren Benutzer ist das Nutzen von sudo ohne der Anpassung der Datei /etc/sudoers oder der Gruppenzuordnung nicht möglich.

Es hat möglicherweise einen guten Grund, daß dieser Benutzer nicht in dieser Gruppe ist. Daher sollte sich dieser Benutzer in solchen Angelegenheiten besser an den Systemadministrator wenden...

mreczio hat geschrieben:

Ich würde schreiben, daß sich dies auf den ersten angelegten Benutzer bezieht.

Es könnte ja der Artikel sudo als Voraussetzung im "Kentnissblock" erwähnt werden?

mreczio hat geschrieben:

Wobei der Benutzer auch ohne sudo die Rechte an seinem Homeverzeichnis mittels chown und chmod ändern kann.
Also sudo nicht notwendig ist.

Bei chown ist sudo sehr wohl notwendig, wenn der Eigentümer verändert werden soll. Bei der Gruppe ist sudo nur dann nicht notwendig, wenn es eine Gruppe ist, der der Benutzer zugewiesen ist. Bei chmod kann er nur dann auf sudo verzichten, wenn er auch Eigentümer seines Verzeichnisses/seiner Dateien ist. Aber der Artikel behandelt ja gerade den Fall, daß dies - dummerweise - nicht der Fall ist... (Ich hoffe, ich habe keinen Sonderfall übersehen...)

DrScott hat geschrieben:

mreczio hat geschrieben:

Für einen weiteren Benutzer ist das Nutzen von sudo ohne der Anpassung der Datei /etc/sudoers oder der Gruppenzuordnung nicht möglich.

Es hat möglicherweise einen guten Grund, daß dieser Benutzer nicht in dieser Gruppe ist. Daher sollte sich dieser Benutzer in solchen Angelegenheiten besser an den Systemadministrator wenden...

Sollte aber als Hinweis rein

DrScott hat geschrieben:

mreczio hat geschrieben:

Wobei der Benutzer auch ohne sudo die Rechte an seinem Homeverzeichnis mittels chown und chmod ändern kann.
Also sudo nicht notwendig ist.

Bei chown ist sudo sehr wohl notwendig, wenn der Eigentümer verändert werden soll. Bei der Gruppe ist sudo nur dann nicht notwendig, wenn es eine Gruppe ist, der der Benutzer zugewiesen ist. Bei chmod kann er nur dann auf sudo verzichten, wenn er auch Eigentümer seines Verzeichnisses/seiner Dateien ist. Aber der Artikel behandelt ja gerade den Fall, daß dies - dummerweise - nicht der Fall ist... (Ich hoffe, ich habe keinen Sonderfall übersehen...)

Also geht man davon aus, dass andere Benutzer schon Daten in diesem Verzeichnis abgelegt haben.
Nur für diesen Fall wäre ja dann ein sudo notwendig

mreczio hat geschrieben:

Also geht man davon aus, dass andere Benutzer schon Daten in diesem Verzeichnis abgelegt haben.
Nur für diesen Fall wäre ja dann ein sudo notwendig

Ich bin jetzt nicht sicher, ob ich dich richtig verstehe...

Normalerweise können Benutzer in fremden Homeverzeichnissen gar keine Dateien erstellen. Im Artikel geht es eigentlich um den häufigen Fall, daß der Anwender, der auch sudo ausführen darf, unabsichtlich sich seine eigenen "Rechte" entzieht und dann nicht mehr weiter weiß...

Ich hab jetzt sudo verlinkt sowie einen Hinweis reingesetzt, dass sich die Problemlösung um fehlende Rechte an Ubuntu-Heimanwender richtet und Mitglieder eines Netzwerkes sich an ihren Admin wenden sollen.

Hab den Artikel Homeverzeichnis aus der Baustelle verschoben.

Matthias hat geschrieben:

Hab den Artikel Homeverzeichnis aus der Baustelle verschoben.

Waren wir uns denn einig wie wir die Angaben bei

Homeverzeichnis#head-d4c08bd5fddb7d16a55ef2b9f74f2516ebafb9e9
→ Rechte

optimal setzen?

Ich war möglicherweise etwas voreilig. Der Artikel ist wieder in der Baustelle mit Link zu dieser Diskussion.

sudo chown $USER:$USER $HOME -R
cd $HOME
find  -type d -exec chmod 755 {} \;
find  -type f -exec chmod 644 {} \;

Im ersten Befehl wird das Homeverzeichnis des aktuellen Benutzers wieder diesem zugewiesen, im Zweiten wechselt man in das Homeverzeichnis, im dritten und vierten Schritt sucht man mittels Shell/find alle Dateien bzw. Verzeichnisse und weist diesen die richtigen Rechte zu.

Ich bin nach wie vor der Meinung, dass hiermit mehr Schaden als Nutzen herbeigeführt wird. Durch 644 auf bestimmte versteckte Dateien werden evtl. Passwörter oder ähnlich sensible Daten gefährdet. Manche sicherheitsbewussten Programme verweigern sogar komplett den Start (fetchmail) oder schränken ihre Funktionalität ein (sshd), wenn sie zu lasche Rechte an ihren Konfigdateien entdecken. Der Sinn ist mir auch überhaupt nicht klar. Anscheinend muss auf irgendwelchen älteren Systemen die Datei .dmrc 644 haben (bei mir hat sie jedenfalls 600 und ich kann mich offensichtlich einloggen), aber welche andere Datei im Homeverzeichnis muss noch zwingend irgendwelche Rechte für Gruppen oder sogar Andere haben?

Deswegen bin ich für folgenden Codeblock:

sudo chown $USER:$USER $HOME -R
chmod -R u+rwX ~
chmod 644 ~/.dmrc  # nur falls das auf irgendeinem aktuell unterstützten System wirklich notwendig ist

Beachtet, dass find komplett überflüssig wird dank dem großen X. (Siehe man chmod.)

Homeverzeichnis nur für den eigenen Benutzer lesbar

Wenn euch schon meine o.a. Argumente (public_html, intuitive Lesefreigabe für einzelne Dateien per Nautilus) nicht vom x-Bit überzeugen, dann vielleicht das, dass die Rechte konsistent zu dem sein sollten, was der folgende Abschnitt mit dpkg-reconfigure global macht, und das ist 751. Die umask sollte in diesem Fall auf jeden Fall mit beachtet werden. Mit umask 027 ist man dann aber auf der sicheren Seite. Ein stichhaltiges Argument gegen diese Vorgehensweise habe ich hier noch nicht entdecken können.

(echo; echo umask 027) >> ~/.bashrc  # muss man das noch woanders eintragen, damit's für den gesamten Desktop gilt?
chmod -R o-rwx $HOME
chmod o+x $HOME
chmod 644 ~/.dmrc  # siehe Anmerkung oben

Voreinstellung ändern
Wenn man die Voreinstellung ändern möchte, so dass die Dateien künftig neu angelegter Benutzer nicht von Anderen lesbar sind, so geht das im Terminal ^[1] mit dem Befehl

sudo dpkg-reconfigure adduser

Die Frage "Wünschen Sie systemweit lesbare Heimatverzeichnisse" sollte man hier dann mit einem "Nein" beantworten.

Hier sollte auch die umask mit rein, da ansonsten ein Informationsleck entsteht. Also:

sudo dpkg-reconfigure adduser
sudo sed -ie 's/^umask.*$/umask 027/' /etc/profile

Und dann noch etwas genauer betonen, dass das nur für neue Benutzer gilt, und man für alte Benutzer die andere Methode verwenden muss.

Bezüglich "Rechte wiederherstellen" finde ich Otzenpunks Vorschlag optimal. Ich würde hier nur dafür plädieren, bei einer Schreibweise für $HOME zu bleiben. Also entweder $HOME oder '~'. Ich persönlich tendiere - in diesem Kontext - zu $HOME.

Zum Abschnitt "Home nur für den eigenen Benutzer freigeben": Ich kann Otzenpunks Beweggründe verstehen, jedoch widerspricht das etwas der Überschrift. Es heißt ja "Home _nur_ für den eigenen Benutzer freigeben". Ein Leser dieses Artikels darf daher meiner Meinung nach davon ausgehen, daß dies nach Anwendung der beschriebenen Befehle auch so ist. Daher sollte meiner Meinung nach wirklich kein anderer Benutzer zugreifen dürfen, auch www_run nicht... Ansonsten muß das unbedingt klar gemacht werden.

Ich denke, den Spagat (einfach&sicher vs. ziemlich sicher, aber einige Lockerungen) werden wir nicht hinkriegen. Wie wäre es, tatsächlich Varianten anzubieten? Mit einer kurzen Diskussion der Vor- und Nachteile? Vorschlag:

Variante1: sudo chmod 7^[5]0 $HOME (also ohne -R!)
Variante2: Otzenpunks Vorschlag

Sicherheit ist nun mal ein komplexes Thema, daher sollten die Beschreibungen durchaus etwas weiter ausholen und die jeweiligen Vor- und Nachteile - in dieser Diskussion haben sich ja einige herausgestellt - ansprechen.

Meine Vorstellung (vielleicht nicht komplett...):

Variante 1:
Vorteile:
* Einfaches, wirkungsvolles Konzept. Schutz unabhängig von den jeweiligen Datei-/Verzeichnisrechten
* Rechte innerhalb von $HOME bleiben unberührt ⇒ komplett umkehrbar
* (700) absolut dicht
* (750) über die Gruppe _kann_ anderen selektiv Zugang gewährt werden

Nachteile:
* Andere "gute" Benutzer/Dienste könnten behindert werden. Beispiel apache
* kann für neue Benutzer nicht automatisiert werden.

Variante 2:
Vorteile:
* Programme/Serverdiesnte können "durchgelassen" werden
* Kann mit "dpkg-reconfigure adduser ... + umask->/etc/profile" zum Systemstandard gemacht werden

Nachteile:
* Änderung der umask erforderlich
* Rechte unter home werden verändert ⇒ Nicht komplett umkehbar
* Programme bzw. der Anweder können durch falsche Rechtevergabe eine Datei/Verzeichnis "offenlegen"

DrScott hat geschrieben:

Bezüglich "Rechte wiederherstellen" finde ich Otzenpunks Vorschlag optimal. Ich würde hier nur dafür plädieren, bei einer Schreibweise für $HOME zu bleiben. Also entweder $HOME oder '~'. Ich persönlich tendiere - in diesem Kontext - zu $HOME.

*zustimm*
DrScott hat geschrieben:

Zum Abschnitt "Home nur für den eigenen Benutzer freigeben": Ich kann Otzenpunks Beweggründe verstehen, jedoch widerspricht das etwas der Überschrift. Es heißt ja "Home _nur_ für den eigenen Benutzer freigeben". Ein Leser dieses Artikels darf daher meiner Meinung nach davon ausgehen, daß dies nach Anwendung der beschriebenen Befehle auch so ist.

Ist ja auch so. Nach der Änderung kann www-data zwar das Verzeichnis betreten, aber nicht auflisten und auch sonst nichts dort tun, da alle Dateien/Verzeichnisse unles-/-schreib-/-ausführbar sind. Durch die Umask gilt das auch für alle neu erzeugten Dateien. Die einzige Möglichkeit für andere Benutzer, irgendwas dort zu tun, ist wenn der Besitzer auf einem Objekt explizit erweiterte Rechte setzt. Das würde, denke ich, auch den Erwartungen entsprechen.
DrScott hat geschrieben:

Variante 1:
Vorteile:
* Rechte innerhalb von $HOME bleiben unberührt ⇒ komplett umkehrbar

Das ist eigentlich das einzige, was in der Tat für diese Variante spricht. Aber ob das alleine die Erwähnung nun rechtfertigt? Selbst wenn man das mal umkehren möchte, muss man anderen Benutzern seine versteckten Verzeichnisse sowieso nicht wieder offenbaren. Und bei den Sichtbaren kann man es imho auch von Hand tun.
DrScott hat geschrieben:

* (750) über die Gruppe _kann_ anderen selektiv Zugang gewährt werden

Kann man nicht. Es gibt eine Gruppe, die den Namen des Benutzers trägt. Nur diese kann das Homeverzeichnis betreten. Wenn man nun jemand anderen in diese Gruppe aufnimmt, kann man überhaupt nicht (bzw. nur unter großem Aufwand) "selektiven Zugriff" erlauben, sondern dieser Benutzer kann dann erstmal alles lesen, was sich im Home befindet.
DrScott hat geschrieben:

Variante 2:
Nachteile:
* Programme bzw. der Anweder können durch falsche Rechtevergabe eine Datei/Verzeichnis "offenlegen"

Sollte aber eigentlich nicht "aus Versehen" passieren.

otzenpunk hat geschrieben:

DrScott hat geschrieben:

Variante 1:
Vorteile:
* Rechte innerhalb von $HOME bleiben unberührt ⇒ komplett umkehrbar

Das ist eigentlich das einzige, was in der Tat für diese Variante spricht. Aber ob das alleine die Erwähnung nun rechtfertigt?

Es ist zudem noch absolut und einfach. Es hängt auch nicht von den darunterliegenden Rechten ab. Die sind egal. Im Gegensatz zur Variante 2.
otzenpunk hat geschrieben:

DrScott hat geschrieben:

* (750) über die Gruppe _kann_ anderen selektiv Zugang gewährt werden

Kann man nicht. Es gibt eine Gruppe, die den Namen des Benutzers trägt. Nur diese kann das Homeverzeichnis betreten. Wenn man nun jemand anderen in diese Gruppe aufnimmt, kann man überhaupt nicht (bzw. nur unter großem Aufwand) "selektiven Zugriff" erlauben, sondern dieser Benutzer kann dann erstmal alles lesen, was sich im Home befindet.

Das selektiv hat sich nicht auf Dateien, sondern auf Benutzer bezogen: Manche Benutzer dürfen weiterhin so zugreifen, wie das normalerweise der Fall ist
otzenpunk hat geschrieben:

DrScott hat geschrieben:

Variante 2:
Nachteile:
* Programme bzw. der Anweder können durch falsche Rechtevergabe eine Datei/Verzeichnis "offenlegen"

Sollte aber eigentlich nicht "aus Versehen" passieren.

Du kennst Murphy? 😉 Genau da liegt meiner Meinung der Vorteil von Variante1: Unterhalb von $HOME sind die Rechte egal. Es kann nichts passieren...

Naja, was Murphy anbelangt, kann es bei Variante 1 auch "sehr schnell" dazu kommen, dass man aus Versehen wieder die Rechte am Homeverzeichnis lockert, (z.B. weil irgendwas wie public_html nicht funktioniert und jemand im Forum einen Tipp gibt,) und dann ist wieder alles offen, was bei Variante 2 auf Grund der Umask nicht der Fall wäre.

Deswegen bin ich nach wie vor gegen Variante 1. Wenn sie aber doch rein kommt, würde ich das mit der Gruppe und 750 weglassen und einfach explizit schreiben, dass man dann niemals irgendeine Datei freigeben kann, was auch nicht-offensichtliche Verwendungsmöglichkeiten wie public_html mit einschließt.

Sodalle, was lange währt wird endlich gut ☺

Baustelle/Homeverzeichnis

Otzenpunk und Ich sind der Meinung, dass man den Artikel nun ins Wiki stellen kann.