staging.inyokaproject.org

Servus ☺

habe mal bis Baustelle/Samba_Client_cifs#Optionen etwas Syntax gefixt.

• Fett ausschließlich für Paketnamen und Dateien und Verzeichnisse

• Befehle im Fließtext bitte monotype formatieren

Zu den Optionen: Kann man nicht für auto, users, simulierte Dateirechte und Zeichensatz einfach auf mount#Optionen verweisen? Redundanz und so... Dann blieben nur cifs-typische Optionen über, was IMHO besser wäre.

Gruß
kaputtnik

Danke fürs Syntax fixen! Der gefixte Teil stammt ja größtenteils aus dem alten Artikel. Also hätte man da schon mal nach der Syntax sehen können.

Kann man nicht für auto, users, simulierte Dateirechte und Zeichensatz einfach auf mount#Optionen verweisen?

Habe ich auch überlegt. Doch ich habe die in diesem Zusammenhang gebräuchlichsten Optionen hier hereingenommen, weil in dem besagten Artikel mount so viel drin steht, dass man leicht vor Bäumen den Wald nicht mehr sieht. Das meiste davon braucht man hier gar nicht.

Was die Redundanz angeht, handelt es sich hier gerade mal um 6 Zeilen. Genau genommen sogar nur um 4, denn bei user und users treten bei cifs bereits Unterschiede zu anderen Dateisystemen auf. und der wichtige Hinweis, dass auto nur dann funktioniert, wenn das Netzwerk bereits verfügbar ist, gehört ja auch hier her. Ich würde sie drin lassen, um unnötiges Hin- und Herwechseln zu vermeiden. Den von Dir gewünschten Verweis kann ich außerdem einfügen, kein Problem. "Das Eine tun und das Andere nicht lassen".

Gruß - Max-Ulrich

Servus ☺

Max-Ulrich Farber schrieb:

Danke fürs Syntax fixen! Der gefixte Teil stammt ja größtenteils aus dem alten Artikel. Also hätte man da schon mal nach der Syntax sehen können.

Stimmt...

Habe ich auch überlegt. Doch ich habe die in diesem Zusammenhang gebräuchlichsten Optionen hier hereingenommen, weil in dem besagten Artikel mount so viel drin steht, dass man leicht vor Bäumen den Wald nicht mehr sieht.

IMHO OK ☺

BIn ansonsten durch und mir sind noch ein paar Sachen aufgefallen:

Konstrukte im Artikel-Code wie:

Text {{{
Code}}}\\
\
{{{ code
}}}

sind schwer zu Pflegen. Na andere Lösung ist mir aber auch nicht eingefallen...

Das steht zweimal drin:

sleep 20
mount -a

Einmal ←> Zweimal. Im zweiten Vorkommen wird das Vorgehen in einem Hinweisblock als dprecated bezeichnet.

Es sind noch ein paar auskommentierte Zeilen drin. Sollen die drin bleiben?

Ansonsten ok ☺

Gruß
kaputtnik

...sind schwer zu pflegen. Ne andere Lösung ist mir aber auch nicht eingefallen...

Mir eben leider auch nicht.

Das steht zweimal drin:

sleep 20
mount -a

Stimmt. Genau genommen sogar dreimal. Ich habe es oben schon im Abschnitt Systemweites Automount mit hereingenommen, weil es inzwischen bei WLAN fast immer nötig ist, also keine Ausnahme mehr darstellt. Unten (bei den Problemen) habe ich es nur deshalb vorerst noch dringelassen, weil AFAIK in verschiedenen Threads darauf verwiesen (verlinkt) wurde. Kann ich aber auch rausmachen. Beim dritten Mal handelt es sich aber um ein anderes Problem, das auf die gleiche Weise zu lösen ist.

Im zweiten Vorkommen wird das Vorgehen in einem Hinweisblock als dprecated bezeichnet.

Ja, früher (2009) wurde angekündigt, dass rc.local wegfallen sollte, wenn Upstart durchgängig eingeführt ist. Ob das je einmal kommen wird, weiß ich nicht. Aber auch mit Upstart wird man wohl auf irgendeine Datei, die am Ende des Bootvorganges abgearbeitet wird, nicht völlig verzichten können(??). Bis dahin wird es rc.local sicher noch geben. Ich weiß derzeit keine Alternative dafür.

Gruß - Max-Ulrich

Max-Ulrich Farber schrieb:

Stimmt. Genau genommen sogar dreimal. Ich habe es oben schon im Abschnitt Systemweites Automount mit hereingenommen,

Ach deswegen kam es mir bekannt vor 🤣

Ok, vllt kann noch ein zweiter KOntrollesen? Der Artikel ist doch ganz schön umfangreich...

Danke ☺
kaputtnik

Ok, vllt kann noch ein zweiter KOntrollesen?

Ja, gerne, damit nicht wieder ein paar Syntaxfehler durch die Lappen gehen - wie beim Vorgänger! 😉

EDIT:

Ich habe jetzt den Doppel-Eintrag zwar nicht gelöscht (wegen möglicher Links aus dem Forum), aber durch einen internen Link ersetzt.

Hi!

Noch mal durchgeschaut, und zurückgeschoben: Samba Client cifs

Besten Dank an Max-Ulrich_Farber!

so long
hank

Ich fände es angebracht, wenn die Warnung in dem Artikel bezüglich des SUID-Bits unter Lucid bzw. früher, konkretisiert würde.

Wenn ich mal davon ausgehe, dass ich z.B. meine Daten zuhause auf einem NAS sichern will, auf dem dafür eine Freigabe besteht, wo liegt denn dann die konkrete Gefährdung durch Setzen des SUID-Bits? Ist es nicht so, dass ein Risiko nur dann besteht, wenn überhaupt mehrere Freigaben für unterschiedliche Benutzer bestehen, die dann aufgrund des SUID-Bits jede dieser Freigaben einhängen könnten, egal ob für sie bestimmt oder nicht?

Oder kann ich mit mount.cifs noch anderes Unwesen anstellen?

Gruß, Martin

@Newubunti:

Oder kann ich mit mount.cifs noch anderes Unwesen anstellen?

Ja, schon. Wegen der cifs-UNIX-Extensions kann man z.B. von einem Client aus mittels mount.cifs Dateirechte, Zeitstempel usw. auf dem Server verändern. Bis vor Kurzem konnte man sogar Softlinks einrichten, mit denen man direkt ins Root-Verzeichnis des Servers gelangen konnte. Letzteres ist aber jetzt (weitgehend) unterbunden. Welche anderen Risiken es vielleicht sonst noch gibt, weiß ich nicht.

wo liegt denn dann die konkrete Gefährdung durch Setzen des SUID-Bits?

Das hängt vom einzelnen System ab. Ohne die UNIX-Extensions ist IMHO das Risiko gering, eben nur das, was Du anführst.

Wenn ich mal davon ausgehe, dass ich z.B. meine Daten zuhause auf einem NAS sichern will ...

... und Du nicht damit rechnen musst, dass halbwüchsige Kinder versuchen, in deinem NAS herumzustöbern, gibt es IMHO kein Risiko.

Ich finde auch, im privaten Bereich ist das Risiko gering, oder es gibt gar keines. Im produktiven Bereich kann dies freilich ganz anders sein.

Die Warnung beim SUID-Bit ist auch eine Art routinemäßige Absicherung gegen Vorwürfe bei Fehlern durch Unachtsamkeit.

Gruß - Max-Ulrich

Max-Ulrich Farber schrieb:

@Newubunti:

Oder kann ich mit mount.cifs noch anderes Unwesen anstellen?

Bis vor Kurzem konnte man sogar Softlinks einrichten,...

Ok, danke, das wusste ich nicht. Was heißt bis vor kurzem? Ist das für Lucid noch aktuell? Ansonsten ist das allerdings dann schon ziemlich "broken by Design", um es mal gelinde auszudrücken.

Ja, schon. Wegen der cifs-UNIX-Extensions kann man z.B. von einem Client aus mittels mount.cifs Dateirechte, Zeitstempel usw. auf dem Server verändern.

Das ist bzw. wäre jetzt mal solange noch nicht die "Gefahr", solange das nur auf dem freigegebenen Ordner auf dem Server funktioniert.

Was ich bei mount.cifs nicht verstehe ist, warum es nicht einfachere Möglichkeit gibt, eine Freigabe, die ich auf dem Server für einen bestimmten Benutzer einrichte - und zwar den, mit dem ich vom Client dann aus für's Backup mounten will - persönlich in einen Ordner unterhalb von /home einzuhängen, ohne dem Benutzer Rechte für das generelle Mounten für Freigaben einzuräumen. Dies Aussage bezieht sich auf Lucid und geht davon aus, dass ich den Artikel nicht missverstanden habe.

Ab Maverick geht es ja dann wieder, so wie ich es auch erwarten würde, über die fstab.

@Max-Ulrich Farber: Bitte nicht persönlich nehmen, weil Du kannst ja nichts dafür, dass es so ist - wenn es denn so ist.

Gruß, Martin

Ist das für Lucid noch aktuell?

Nein, dieses Sicherheitsleck wurde dadurch gestopft, dass die Optionen follow symlinks = yes und wide links = yes nicht mehr Standard sind und außerdem meines Wissens auch nicht mehr zusammen mit unix extensions = yes gewählt werden können. Aber ganz klar ist mir nicht, was jetzt immer noch geht und was nicht. Diese Änderungen wurden in einer "Nacht- und Nebel-Aktion" bei einem Samba-Update wortlos mit untergejubelt, und viele verstanden nicht, warum die ganze Softlinkerei plötzlich nicht mehr ging. Und das betraf nicht wenige.

Ab Maverick geht es ja dann wieder, so wie ich es auch erwarten würde, über die fstab.

Über die fstab ging es ja immer. Das Gefährliche war nur, dass es auch ohne ging, und sogar viel bequemer. Und das wurde jetzt abgestellt (unabhängig von obiger Korrektur).

Bitte nicht persönlich nehmen, weil Du kannst ja nichts dafür, dass es so ist

Keine Gefahr, ich nehme nichts persönlich. Ich fühle mich auch in keiner Weise für die Stärken und Schwächen von Samba verantwortlich.

Zurück zum Wiki: Ich denke, wir lassen die Warnung in dieser unbestimmten Form drin. Sie bringt einerseits zum Ausdruck, dass man mit Samba schon ein bisschen vorsichtig sein muss, und klingt andererseits ein bisschen nach "nix genaues weiß man nicht", was ja ehrlicherweise auch stimmt.

Gruß - Max-Ulrich

Danke, stfischr, für die Ergänzung im Teil Shutdown und Reboot.

Ich werden vielleicht Deine Skripte erst hinter dem Satz "Das Problem lässt sich dadurch umgehen, dass man die systemweit eingebundenen Freigaben vor dem Herunterfahren manuell aushängt" anbringen, und zwar das zweite, einzeilige Skript zuerst mit einem Shebang, sodass man dafür einen Starter anlegen kann. Ich denke, das muss gehen, wenn man im fstab-Eintrag die Option users einfügt. Das gibt dann eine Überleitung zum config-Skript in /etc/init. Ich würde das kurze, einzeilige Skript dann auch nicht dort unterbringen, denn in /etc/init befinden sich üblicherweise keine ausführbaren Shell-Skripte. Mal suchen, wohin es besser passt.

Doch dies alles kann ich erst morgen oder am Sonntag machen.

Gruß - Max-Ulrich

Ja, das war alles Neuland für mich, von daher habe ich das einfach geguttenbergt. 😉 Also immer her mit Optimierungen.

von daher habe ich das einfach geguttenbergt. 😉

Ein Wiki ist keine Dissertation. Da ist das absolut legal, und es hat auch niemand etwas dagegen. ☺

EDIT:

Ich habe jetzt die Umstellungen in der Reihenfolge und die (kleinen) Korrekturen vorgenommen. Dabei sind mir aber noch 2 Dinge aufgefallen:

1. Theoretisch müsste das Shutdown-Problem eigentlich genau so auch bei NFS auftreten, wenn man zum Verbinden mit einem verschlüsselten WLAN einen der Netzwerk-Manager verwendet. Weiß hier jemand Bescheid?

2. Abschnitt "Probleme beim Versand größerer Datenmengen" (stammt nicht von mir): Ist dieser überhaupt bei den neueren Samba-Versionen noch aktuell? Außerdem kann das Workaround so nicht funktionieren; die Option noauto im fstab-Eintrag und der Befehl sudo mount -a gehen nicht zusammen. Schließlich müsste auch auf die Gefahren beim Abschalten von File-Locking unbedingt hingewiesen werden!

3. Stimmt der Hinweis, rc.local sei "deprecated" noch? Vor ca. 2 Jahren war davon öfters die Rede, aber rc.local ist bis jetzt keineswegs verschwunden - und wohl auch kaum ersetzbar. Ich würde den Hinweis deshalb gerne entfernen. Weiß da jemand Näheres?

Gruß - Max-Ulrich

EDIT:

noch 2 Dinge aufgefallen

Eben sehe ich, es sind deren drei. Auf drei zählen ist halt nicht jedermanns Sache 🐸 .

Hallo,

Im Folgenden wird zwischen "systemweitem" und "persönlichem" Einbinden unterschieden:

• Systemweites Einbinden: Um Freigaben mittels mount.cifs bzw. mount -t cifs systemweit einzubinden, werden Root-Rechte benötigt.

• Persönliches Einbinden: Um Freigaben auch ohne Root-Rechte persönlich einbinden und wieder aushängen zu können, muss für mount.cifs und ggf. für umount.cifs das SUID-Bit gesetzt sein.

• Ab Ubuntu 10.10 ist das SUID-Bit für /sbin/mount.cifs standardmäßig gesetzt. Dies ist kein Sicherheitsrisiko, weil mount.cifs trotzdem nur dann ohne Root-Rechte aufgerufen werden kann, wenn dies durch einen entsprechenden Eintrag in /etc/fstab ermöglicht wird. Der Befehl umount.cifs existiert nicht mehr.

• Bis Ubuntu 10.04 können mount.cifs und umount.cifs bei gesetztem SUID-Bit auch ohne Eintrag in /etc/fstab von jedermann ausgeführt werden! Da dies ein Sicherheitsrisiko sein kann, ist das SUID-Bit für diese Routinen in Ubuntu 10.04 nicht mehr standardmäßig gesetzt. Man muss dafür in einem Terminal folgende Befehlszeilen eingeben:

  sudo chmod +s /sbin/mount.cifs
  sudo chmod +s /sbin/umount.cifs 

  Es kann sein, dass bei Updates von cifs-utils oder smbfs das SUID-Bit zurückgesetzt wird und es deshalb danach neu zu setzen ist.

  Achtung!

  Der Einsatz des SUID-Bit ist eine mögliche Sicherheitslücke und sollte nur mit Bedacht verwendet werden.

Diese Hinweise sind doch eher für Experten gedacht. Oder? "normale" Anwender verwirrt das vermutlich doch nur. Wäre da nicht ein Expertenkasten richtig?

MfG, Daniel