staging.inyokaproject.org

Hallo,

ich bin im Abschnitt Homeverzeichnis nur für den eigenen Benutzer lesbar über folgenden Satz gestolpert:

In den Standardeinstellungen darf jeder Benutzer alle Daten anderer Benutzer lesen, aber nicht schreiben.

Diese Aussage ist doch offensichtlich falsch. Oder habe ich ein Brett vor dem Kopf?

Zwar lautet der Dateimodus innerhalb eines Homeverzeichnisses 0664 und jeder Benutzer könnte diese Dateien damit theoretisch lesen, doch beträgt der Dateimodus für das Homeverzeichnis selbst 0700. Außer dem Besitzer und root kommt niemand in das Verzeichnis hinein, um Dateien darin zu lesen. Dieser Umstand widerlegt die oben zitierte Aussage.

Kann das jemand bestätigen? Falls ja, würde ich den Satz um die Information ergänzen, dass dies nur gilt, wenn man anderen Benutzern Zugang zum eigenen Homeverzeichnis gewährt.

MfG
Tronde

Tronde schrieb:

[…] Zwar lautet der Dateimodus innerhalb eines Homeverzeichnisses 0664 und jeder Benutzer könnte diese Dateien damit theoretisch lesen, doch beträgt der Dateimodus für das Homeverzeichnis selbst 0700.

• Bei mir (Ubuntu GNOME 16.04) ist die Standardeinstellung für das Homeverzeichnis selbst 0755. Wie im Artikel beschrieben kann jeder Benutzer das selbst auf 0700 ändern.

[…] würde ich den Satz um die Information ergänzen, dass dies nur gilt, wenn man anderen Benutzern Zugang zum eigenen Homeverzeichnis gewährt.

• Es ist umgekehrt wie Du meinst:

  • Standardeinstellung beim Anlegen eines Benutzers ist 0755 für die Rechte des Homeverzeichnisses.

  • Jeder Benutzer kann für Fremde den Zugriff auf Dateien in seinem Homeverzeichnis verweigern.

• Die Darstellung im Artikel ist richtig.

• Ich bin allerdings selbst unsicher, ob das setzen der Rechte des Homeverzeichnisses auf 0700 ausreicht, um das Lesen einer Datei in diesem Verzeichnis in allen Lebenslagen zu verhindern – finde aber kein Gegenbeispiel.

Hallo,

Bei mir (Ubuntu GNOME 16.04) ist die Standardeinstellung für das Homeverzeichnis selbst 0755.

Ist unter Ubuntu Trusty 14.04 auch so.

Gruß, noisefloor

Guten Morgen,

ich muss mich korrigieren, ihr habt Recht. Zur Sicherheit habe ich gerade noch einmal einen neuen Benutzer mittels adduser erstellt und die Berechtigungen seines Homeverzeichnisses geprüft. Diese lautet tatsächlich 0755.

Tatsächlich konnte ich mir nicht vorstellen, dass ich die Rechte auf all meinen Systemen angepasst habe, so dass dort kein anderer Benutzer mein Homeverzeichnis betreten und Dateien daraus lesen kann.

Danke, dass ihr das Brett vor meinem Kopf entfernt habt.

LG
Tronde

Hallo zusammen!

Benutzer-Programme wie Root-Programme starten¶

Möchte man Anwendungen oder Skripte starten, die man direkt im Homeverzeichnis abgelegt und nicht "korrekt" installiert hat, so muss man zum Starten den Pfad angeben. Dies liegt daran, dass nur eine Reihe von Verzeichnissen in der PATH Umgebungsvariable aufgelistet werden. Für Skripte unbekannter Herkunft ist dieser Vorschlag ungeeignet, da er zu einer potentiell gefährlichen Rechte-Eskalation führen kann.

Um trotzdem komfortabel eigene Programme oder Skripte starten zu können, kann man im Homeverzeichnis ein Verzeichnis mit dem Namen bin erstellen und dort Skripte oder Anwendungen ablegen bzw. verlinken. Das Verzeichnis $HOME/bin wird, sofern es existiert, nach der Anmeldung automatisch in der PATH-Umgebungsvariable eingetragen.

So mitten im Fließtext ist der markierte Satz IMHO verwirrend. Wäre es nicht besser, ihn (eventuell etwas abgewandelt) in eine Hinweis- bzw. Warn-Box verpackt entweder an den Anfang oder das Ende des Abschnittes zu stellen?

Hallo,

Wäre es nicht besser, ihn (eventuell etwas abgewandelt) in eine Hinweis- bzw. Warn-Box verpackt entweder an den Anfang oder das Ende des Abschnittes zu stellen?

Ja, macht Sinn, als beides. Hast du eine Idee.

BTW: was ist eine "Rechte-Eskalation"?

Gruß, noisefloor

noisefloor schrieb:

BTW: was ist eine "Rechte-Eskalation"?

Vermutlich ist eine Rechteausweitung aka privilege escalation gemeint.

Hallo,

wenn's so wäre, wäre es aber nicht korrekt, weil man den Prog ja durch den expliziten Aufruf mit sudo (=Root-Rechten) dem Prog alle Rechte einräumt.

Sollte man dann vielleicht auch direkt etwas präzisieren.

Gruß, noisefloor

Hallo zusammen,

noisefloor schrieb:

Hallo,

wenn's so wäre, wäre es aber nicht korrekt, weil man den Prog ja durch den expliziten Aufruf mit sudo (=Root-Rechten) dem Prog alle Rechte einräumt.

Sollte man dann vielleicht auch direkt etwas präzisieren.

Gruß, noisefloor

wohin aber soll denn bitteschön genau präzisiert werden?

• Dahin, dass man wirklich Benutzer-Programme wie Root-Programme starten kann? Dann wäre in der Tat der Verweis auf den expliziten Aufruf mit sudo (=Root-Rechten) angebracht, aber alles bzgl. der PATH Umgebungsvariable müsste entfernt werden!

• Oder ist die Überschrift Benutzer-Programme wie Root-Programme starten schlichtweg ein Missverständnis? IMHO ja, und ich habe auch schon eine Vermutung, woher es stammen könnte: nämlich wohl daher, dass in Umgebungsvariable/typische Anwendungsfälle (Abschnitt „PATH-erweitern“) lediglich die systemweite Erweiterung von PATH beschrieben wird, nicht aber die benutzerspezifische! Wegen dieses Umstandes habe ich übrigens bereits soeben in der entsprechenden Artikel-Diskussion diesen Änderungs-Vorschlag eingebracht.

  • Die Abschnitts-Überschrift müsste IMHO z.B. in Benutzer-Programme einfacher starten abgeändert werden und der Text dann in etwa so aussehen:

Möchte man Anwendungen oder Skripte starten, die man direkt im Homeverzeichnis abgelegt und somit nicht "korrekt" über eine Paketverwaltung installiert hat, so muss man zum Starten deren Pfad angeben. Dies liegt daran, dass nur eine Reihe von Verzeichnissen in der PATH-Umgebungsvariable aufgelistet werden. Siehe auch Programme starten (Abschnitt „Terminal“). (...)

Um trotzdem komfortabel eigene Programme oder Skripte starten zu können, kann man im Homeverzeichnis ein Verzeichnis mit dem Namen bin erstellen und dort Skripte oder Anwendungen ablegen bzw. verlinken. Das Verzeichnis $HOME/bin wird, sofern es existiert, nach der Anmeldung automatisch in der PATH-Umgebungsvariable eingetragen.

• Ergänzende Frage: Wie steht es eigentlich um das Verzeichnis ~/.local/bin? Oder ist das etwa nur für pip-Programme? Antworten dazu aber bitte vorrangig unterhalb von 9107684/, sofern sie nicht explizit diesen Artikel hier betreffen!

Hallo zusammen,

bzgl. meines vorstehenden Vorschlages habe ich hier eine aktualisierte Version, welche

• eine zum Text passende(re) Überschrift hat (die ursprüngliche lautete "bin-Ordner", siehe den Seiten-Anker im Artikel)

  • alternativ könnte auch die jetzige Überschrift beibehalten werden, oder aber ggf. midifiziert werden in "Benutzer-Programme so komfortabel wie Root-Programme starten"

    • wobei dann allerdings im Text der Zusatz angebracht wäre, dass die entsprechenden Programme oder Skripte durch diese Verfahrensweise selbstredend keine Root-Rechte erlangen, sondern dass es dabei lediglich um den höheren Komfort geht

• (damit) die ganzen Missverständnisse betr. Root-Rechten und "potentiell gefährlichen Rechte-Eskalationen" (hoffentlich) von vornherein vermeidet (wenn überhaupt, gehören solche Hinweise nach Fremdsoftware; ein Seiten-Anker auf die alte (bzw. jetzige) Überschrift sollte allerdings angelegt werden)

• ich allerdings erst umsetzen möchte, sobald

  • ich bei Xubuntu 19.10 überprüft habe, ob dort nicht das Verzeichnis $HOME/.local/bin bereits standardmäßig existiert (edit: es existieren dort standardmäßig weder $HOME/.local/bin noch $HOME/bin, aber in der Datei $HOME/.profile ist $HOME/.local/bin bereits standardmäßig aufgeführt; es steht dort ganz unten und wird deswegen – falls es existiert – beim Aufruf von echo $PATH auch ganz vorn bzw. links, also mit der höchsten Priorität, ausgegeben, auch noch vor $HOME/bin, falls dieses denn existiert)

  • die Diskussion um Programme starten (siehe dort unterhalb von 9107684/) betr. dem Verzeichnis ~/.local/bin beendet ist:

Benutzer-Programme komfortabler starten¶

Möchte man Anwendungen oder Skripte starten, die man direkt im Homeverzeichnis abgelegt und somit nicht "korrekt" über eine Paketverwaltung installiert hat, so muss man zum Starten normalerweise deren vollständigen Pfad- und Dateinamen (z.B. ~/skripte/programmname) angeben. Dies liegt daran, dass nur eine Reihe von Verzeichnissen in der PATH-Umgebungsvariable aufgelistet werden. (→ Programme starten (Abschnitt „Terminal“).)

Um trotzdem komfortabel solche Programme oder Skripte starten zu können, kann man entweder direkt im Homeverzeichnis ein Verzeichnis mit dem Namen bin erstellen und dort eigene Skripte oder selbst kompilierte Anwendungen ablegen bzw. verlinken. Oder aber man erstellt (ggf. zusätzlich) im (versteckten) $HOME-Unterordner .local das Verzeichnis bin, worin man dann fremde Skripte und Anwendungen ablegt (→ Programme starten (Abschnitt „Speicherorte-fuer-Programme“)). Die beiden Verzeichnisse $HOME/bin und $HOME/.local/bin werden, sofern sie existieren, nach der Anmeldung automatisch in die PATH-Umgebungsvariable eingetragen.

Hinweis!

Fremdsoftware kann das System gefährden.

Im Artikel heißt es unter https://wiki.ubuntuusers.de/Homeverzeichnis/#Verzeichnisse-loeschen

Möchte man diese vorgegebenen Ordner nicht im eigenen Homeverzeichnis haben, so kann man sie entweder den eigenen Wünschen anpassen oder auch einfach löschen (nicht empfehlenswert!).

Ich habe diese bisher, mit Ausnahme von ~/Downloads, immer gelöscht und die Datei .config/user-dirs.dirs auch nicht angepasst.

Meine Frage ist jetzt nun, hattet ihr jemals echte Nachteile, wenn ihr diese Order mit Ausnahme von Downloads gelöscht habt, außer vielleicht das ihr von einem Programm aus nicht direkt darauf zugreifen konntet, wenn dieses dafür einen Direktzugriff bot?

Weil im Artikel steht das das Löschen nicht empfehlenswert sei. Eine Begründung was passieren könnte, fehlt. Also ist das jetzt nur eine Vermutung des Artikelschreibers oder hat das echte konkrete Nachteile?

Unter echte Nachteile würde ich bspw. verstehen, dass Programme sich seltsam verhalten, nicht richtig funktionieren oder beim Laden ewig brauchen, weil sie Versuchen auf diese Verzeichnisse zuzugreifen und es dann nicht geht. Oder unter bestimmten Umständen wegen gelöschten Ordnern dann abstürzen.

Das ein im Programm angebotener Direktzugriff dann nicht mehr funktioniert ist klar. Aber wenn es den gibt, aber das Verzeichnis gelöscht wurde, dann sollte das Programm entweder so clever sein und im Homedirectory landen oder diesen Direktzugriff in der Auswahl erst gar nicht anbieten. Nur wenn es abstürzt, wenn man auf den Direktzugriff draufklickt, dann wäre das natürlich ein triftiger Grund und ein Nachteil. So einem Programm bin ich bisher aber noch nie begegnet.

Wenn keine trifftigen Gründe für dieses "nicht empfohlen" sprechen, dann schlage ich vor, dass das entfernt wird, weil es den Nutzer nur einschränkt und verängstigt, weil er im glauben, dann würde das alles nicht mehr richtig funktionieren, die Ordner dann einfach lässt (→ einschränkend), obwohl er sie auch genausogut einfach löschen könnte (befreiend).

Hallo,

Weil im Artikel steht das das Löschen nicht empfehlenswert sei. Eine Begründung was passieren könnte, fehlt. Also ist das jetzt nur eine Vermutung des Artikelschreibers oder hat das echte konkrete Nachteile?

Meine _Vermutung_ ist, wie du es im folgenden beschreibst: ggf. vermissen einige Progs den Standardspeicherpfad - wobei die dann halt nach einem anderen Fragen sollten und nicht crashen. Das das Prog nicht startet sollte eigentlich nicht sein, weil die Verzeichnis primär zum Speichern von Daten / Dateien sind, die Konfig-Dateien ja woanders liegen.

IMHO ist das Löschen im allgemeinen nicht empfehlenswert, weil es IMHO für die allermeisten Nutzer keinen sinnvollen Use-Case bzw. keine Vorteile jegliche Art gibt, die Verzeichnisse zu löschen.

Gruß, noisefloor

Cordess schrieb:

Das ein im Programm angebotener Direktzugriff dann nicht mehr funktioniert ist klar. Aber wenn es den gibt, aber das Verzeichnis gelöscht wurde, dann sollte das Programm entweder so clever sein und im Homedirectory landen oder diesen Direktzugriff in der Auswahl erst gar nicht anbieten. Nur wenn es abstürzt, wenn man auf den Direktzugriff draufklickt, dann wäre das natürlich ein triftiger Grund und ein Nachteil. So einem Programm bin ich bisher aber noch nie begegnet.

Wenn keine trifftigen Gründe für dieses "nicht empfohlen" sprechen, dann schlage ich vor, dass das entfernt wird, weil es den Nutzer nur einschränkt und verängstigt, weil er im glauben, dann würde das alles nicht mehr richtig funktionieren, die Ordner dann einfach lässt (→ einschränkend), obwohl er sie auch genausogut einfach löschen könnte (befreiend).

Naja, wie man dem Forum hier entnehmen kann gibt es schon genug User, die damit überfordert sind, der Nautilus-Meldung "Die angeforderte Datei kann nicht gefunden werden", wenn man auf einen der Standard-Links klickt, soweit zu folgen um nachzusehen, ob der Ordner existiert.

Was genau hast du persönlich davon, nicht funktionierende Verknüpfungen im Dateimanager zu haben, außer das du es als "befreiend" empfindest?

Hallo,

ich würde im Text eher noch ergänzen, dass die XDG-USERS-DIRS nicht nur über DEs hinweg, sondern auch von den meisten Linux-Dsitros so eingesetzt werden.

Gruß, noisefloor

noisefloor schrieb:

ich würde im Text eher noch ergänzen, dass die XDG-USERS-DIRS nicht nur über DEs hinweg, sondern auch von den meisten Linux-Dsitros so eingesetzt werden.

Hm? Verstehe ich jetzt nicht. Die Distris an sich benutzen das nicht, nur deren Oberflächen, aber das schon aus Upstream heraus (freedesktop.org-Standards).