[ungelöst gelöst] Nach 'chmod' kein (SSH-)Login mehr möglich

[NAB]

Natürlich sollte man nicht jeden "Furz" an Sicherheitsmechanismus in solche Programme einbauen, doch ich finde gerade wenn es um das "/" geht, sollte dies schon berücksichtigt werden.

Wie? Du willst, dass ich chmod nicht mehr auf / anwenden kann? So ein Blödsinn. Reiß doch einfach deine 7 raus, dann hast du das Problem nie wieder, ohne dass andere Anwender unter deinen Einschränkungen leiden müssen.

Mach einfach
chmod -R 777 /
und dein System läuft wieder.

[hikaru]

Mach einfach
chmod -R 777 /
und dein System läuft wieder.

Das mögen einige Dienste wohl nicht. Die prüfen die Rechte z.B. ihrer config-Dateien (in denen Passwörter stehen könnten) und verweigern die Arbeit, wenn ihnen das Ergebnis nicht passt.

[worker]

Wie? Du willst, dass ich chmod nicht mehr auf / anwenden kann? So ein Blödsinn.

Nö, das hab ich nicht geschrieben. Im Gegenteil. Also, von wegen "wer lesen kann ..."

[Meillo]

.... na gut, Ihr habt Recht und gut ist ....

Those who do not understand UNIX are condemned to reinvent it, poorly.

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.

Das meiste von dem was dir ``falsch'' vorkommt, wird dir irgendwann ``richtig'' vorkommen, wenn du dich nur lange genug mit Unix beschaeftigst.

[Radfahrer]

unter unixoiden Betriebssystemen ist es ueblich, dem Benutzer so wenig unnoetige Hindernisse in den Weg zu legen

Das ist mir schon klar ... leider hat es in meinem Fall (ja, ich weiss, durch meinen eigenen Fehler) Hindernisse geschaffen ^^

Das System hat absolut keine Hindernisse geschaffen. Es hat exakt das gemacht, was du von ihm verlangt hast. Besser geht es doch nicht.
Oder möchtest du ein System haben, das "Nö" sagt, wenn du ihm ein Kommando gibst? Ich nicht.

Lass dich nicht ärgern grins
Du weißt doch: "Wer den Schaden hat...."

[worker]

@Radfahrer:
Iwie glaube ich, dass man in dieser Diskussion nicht wirklich verstehen will, was sinnvoll ist bzw. was ich meinte.
Das das System (hie Linux) durchaus macht, was es soll, das ist doch die Stärke dieses Systems, und JA, man muss schon mit dem Hirn dabei sein, wenn man heikle Dinge macht - keine Frage.
Mir ging es explizit darum, zu zeigen, dass es keinen Sinn macht, wenn ich 'chmod -R 777 /' mache, dass das System dies auch ausführt. Das ist doch genau wie mit dem (bereits hier erwähnten) 'rm -f /' ... aber darauf ging hier ja auch keiner ein.
Eigentlich sollte es doch das Ziel der Programmierer auch sein, genau solche sinnbefreiten Befehlsmöglichkeiten abzufangen (und mit einer Zusatzoption trotzdem zu ermöglichen dies auszuführen - man weiss ja nie, ob nicht doch ausnahmsweise solch ein Fall eintreten könnte, welcher aber im normalen Alltag sinnfrei ist), denn das trägt in Wirklichkeit auch zur Sicherheit bei. Hier geht es nicht um die Bequemlichkeit an sich.
Jeder Mensch macht Fehler und trotzdem ist es sinnvoll gewisse Dinge per Software - aus Sicherheitsgründen - abzufangen. Dieses Feature haben doch etliche Programme. Ich erfinde hier ja auch nichts Neues.

[NAB]

Mir ging es explizit darum, zu zeigen, dass es keinen Sinn macht, wenn ich 'chmod -R 777 /' mache, dass das System dies auch ausführt.

Aber das hast du noch gar nicht gezeigt! Bisher hast du nur 'chmod -R 770 /' gezeigt!

rm -f / ist deswegen blockiert, weil es effizientere und bessere Methoden gibt, das gesamte System zu löschen - falls man das denn wirklich will - und nicht, weil es "sinnfrei" ist. Musst du jetzt aber auch nicht drauf eingehen ...

[owl102]

Eigentlich sollte es doch das Ziel der Programmierer auch sein, genau solche sinnbefreiten Befehlsmöglichkeiten abzufangen

Und wer entscheidet, ob eine Befehlsmöglichkeit sinnbefreit ist oder nicht? Der Entwickler nach gutdünken?

Und wieviele Scripte auf der Welt funktionieren nicht mehr (ohne Änderungen), nachdem solche "sinnbefreit-oder-nicht"-Checks in alle (Nicht-GUI-)Anwendungen eingeflossen sind?

[Meillo]

Iwie glaube ich, dass man in dieser Diskussion nicht wirklich verstehen will, was sinnvoll ist bzw. was ich meinte.

Das liegt halt daran, dass deine Argumentationsweise diejenige ist, die man ueblicherweise erlebt, wenn Unix-Neulinge denken, sie wuessten wie man Unix *richtig* machen muesste. Fast immer liegt es daran, dass sie Unix nicht verstanden haben. Das ist eine Erfahrungsaussage die natuerlich pauschalisiert, aber mit der Zeit wird es halt oede die gleichartige Diskussion immer wieder neu zu fuehren. Wenn ich den Eindruck haette, dass du Unix wirklich gut kennst, dann koennten wir gerne ernsthaft darueber diskutieren. (Ich bin sicher niemand der alles an Unix gut finden wuerde.)

Mir ging es explizit darum, zu zeigen, dass es keinen Sinn macht, wenn ich 'chmod -R 777 /' mache, dass das System dies auch ausführt.

Unix ist inzwischen ueber 45 Jahre alt und chmod(1) gibt es noch immer. Das liegt auch daran, dass es *keine* scheinbar sinnlosen Faelle einschraenkt, denn was Sinn macht und was nicht, das aendert sich in 45 Jahren durchaus mal ... oder auch mehrfach. Aber das wirst du schon auch noch verstehen, wenn du beginnst Unix zu verstehen.

Das ist doch genau wie mit dem (bereits hier erwähnten) 'rm -f /' ... aber darauf ging hier ja auch keiner ein.

Aber ``rm -f /'' ist doch abgesichert:

Code: Alles auswählen

$ rm -f /
rm: cannot remove `/': Is a directory

Und selbst mit `-r' ist es noch abgesichert:

Code: Alles auswählen

$ rm -rf /
rm: cannot remove `/': Permission denied

Wo ist also das Problem?


Lerne erstmal Unix zu verstehen, dann reden wir wieder ueber diese Themen.

[pferdefreund]

und wer hindert dich daran, das chmod -Programm zu kopieren (Quellotext) und ein eigenes mit Sicherheitsabfrage) draus zu machen - eventuell auch einfach ein Wrapper-Script, das den Parameter / abfragt und dann abkackt ? und dann für solche Aktionen nur den eigenen Script oder Programm verwenden. Linux und dessen Software ist frei - und ich halte es so, was mir nicht passt, mache ich mir halt passend.

[worker]

Das ist doch genau wie mit dem (bereits hier erwähnten) 'rm -f /' ... aber darauf ging hier ja auch keiner ein.

Aber ``rm -f /'' ist doch abgesichert:

Code: Alles auswählen

$ rm -f /
rm: cannot remove `/': Is a directory

Und selbst mit `-r' ist es noch abgesichert:

Code: Alles auswählen

$ rm -rf /
rm: cannot remove `/': Permission denied

Wo ist also das Problem?

Das "Problem" ist, dass du bereits der zweite bist, der meine Aussagen nicht richtig liest...
Und btw., als Neuling muss ich mich hier nicht "abstempeln" lassen. Ich mache meine Erfahrungen mit Linux & Co. bereits seit über 10 Jahren.
Ich habe sehr wohl nicht das Tiefe Unix/Linux-Wissen wie Ihr hier, das ist mir durchaus bewusst, aber das muss ich auch nicht wirklich haben, denn man kann sich nunmal nicht in jedem Bereich, den es auf der Welt gibt, sehr gut auskennen.

Wenn man nicht verstehen (oder meiner Argumentation nicht folgen) möchte, worum es mir geht, ist das für mich in Ordnung. Lasst uns das doch einfach mal hier beenden ...

Edit: Uebrigens, ich habe nun das neu aufgesetzte OS mittels eines Scriptchens die Zugriffsrechte des gesamten OS in einer Datei gesichert - nur für den Fall der Fälle

[Meillo]

Das "Problem" ist, dass du bereits der zweite bist, der meine Aussagen nicht richtig liest...

Vielleicht war's nicht verstaendlich genug erklaert ...

Und btw., als Neuling muss ich mich hier nicht "abstempeln" lassen.

Schoen, dass es uns gleich geht, weil du auch nicht richtig gelesen hast, was ich geschrieben habe. Ich habe nur gesagt, dass deine Argumentation der von Neulingen aehnelt.


Dein Tonfall war einfach etwas zu heftig kritisierend an etwas sehr Etabliertem, das in deinem konkreten Fall unguenstige Folgen hatte. Das klang stark nach einer Trotzreaktion nach dem demolierten System. Du wuenschst dir mehr Sicherheit. Das ist ein Fall, der bei Unix-Nutzern, die sich an der Schaerfe des Systems selbst schneiden, typischerweise vorkommt. Die darauf folgende Diskussion fuehrt immer zum gleichen Ergebnis. Alle anderen User im Thread haben auch die gleichen Haltung dazugezeigt ... du bist gegen diese Wand angerannt.

Man kann versuchen so einen Thread einschlafen zu lassen bevor er heftig wird, oder man kann in die Diskussion gehen (von der man weiss, wie sie sehr wahrscheinlich ausgehen wird). Scheinbar warst du dir auch nicht einig, was du willst, weil du einerseits gemeint hast, dass wir das so stehen lassen koennen und andererseits gleichzeitig provozierende Aussagen in den Raum gestellt hast.

Du wirst uns (d.h. alle bisher im Thread Beteiligten und die Jahrzehnte alte Unix-Welt) bestimmt nicht ueberzeugen, dass du es besser weisst. Somit kannst du dich von uns ueberzeugen versuchen lassen (indem wir erklaeren wieso es so ist wie es ist) oder wir lassen es einfach so stehen. Dass wir aber nur zwei harte, gegensaetzliche Standpunkte markieren, ohne dass sich etwas bewegt, das hilft keinem.

[Meillo]

Edit: Uebrigens, ich habe nun das neu aufgesetzte OS mittels eines Scriptchens die Zugriffsrechte des gesamten OS in einer Datei gesichert - nur für den Fall der Fälle

Nicht schlecht! Wenig Aufwand, aber im Fall der Faelle Gold wert.

[worker]

Eigentlich wollte ich wirklich nichts mehr schreiben, aber das kann ich so einfach nicht stehen lassen, denn es ist nicht korrekt was hier geschrieben wird.

Das "Problem" ist, dass du bereits der zweite bist, der meine Aussagen nicht richtig liest...

Vielleicht war's nicht verstaendlich genug erklaert ...

Vielleicht will man es einfach nicht verstehen ...?

Und btw., als Neuling muss ich mich hier nicht "abstempeln" lassen.

Schoen, dass es uns gleich geht, weil du auch nicht richtig gelesen hast, was ich geschrieben habe. Ich habe nur gesagt, dass deine Argumentation der von Neulingen aehnelt.

Ja sicher, das hast du mir ja auch sehr geschickt untergejubelt ^^ ...

Dein Tonfall war einfach etwas zu heftig kritisierend an etwas sehr Etabliertem

Nö. Das ist so einfach nicht korrekt - siehe unten ...

andererseits gleichzeitig provozierende Aussagen in den Raum gestellt hast.

Provozierend sollte das nicht sein - höchstens denen gegenüber, die hier nicht lesen können und mir dann Aussagen unterstellen (wie z.B. hier) welche ich so niemals gemacht habe.

Du wirst uns (d.h. alle bisher im Thread Beteiligten und die Jahrzehnte alte Unix-Welt) bestimmt nicht ueberzeugen, dass du es besser weisst.

Das war auch überhaupt nicht meine Absicht(!).

Somit kannst du dich von uns ueberzeugen versuchen lassen (indem wir erklaeren wieso es so ist wie es ist)

Genau darauf habe ich ja die ganze Zeit gewartet(!).

Bisher konnte mir hier wirklich keiner sagen/erklären, wozu man sein System mit dem Befehl 'chmod -R xxx /' schrotten sollte?
Wobei 'xxx' ja vollkommen schegal ist. Wenn die Rechte schon mal u.a. in /etc, /sbin, usw. im Eimer sind - und wer weiss wo sonst noch in gemounteten Verzeichnissen ...
Diese Kombination von -R und / ist doch tödlich für jedes System?!

Und jetzt darfst du mich gerne eines Besseren belehren, aber bitte mit Logik ...

[NAB]

Bisher konnte mir hier wirklich keiner sagen/erklären, wozu man sein System mit dem Befehl 'chmod -R xxx /' schrotten sollte?

Weil es nicht geschrottet ist ... im Gegenteil, es ist so sehr sicher, da kein einfacher User mehr irgendwas ausführen kann. Perfekt für den reinen Serverbetrieb mit lokalem Admin. Damit, dass du vielleicht auch X, s oder t rekursiv setzen oder löschen möchtest, fange ich jetzt gar nicht erst an. Völlig aus den Socken hauen dürfte dich der Umstand, dass du chmod auch als einfacher User auf / anwenden kannst ... wozu das wohl gut ist?

Deine gesamte Argumentation läuft darauf hinaus, dass du alles, was dir nicht in deine persönlichen Bedürfnisse und (Un)fähigkeiten passt, als "Schrott" bezeichnest.

Dazu ignorierst du, dass du ein Open Source System betreibst ... es steht dir völlig frei, "chmod" beliebig umzuschreiben und an deine Bedürfnisse anzupassen. Aber auch das sollen andere machen ... um deine Fehler zu vermeiden ...

[Meillo]

@NAB: Das war jetzt aber gar nicht konstruktiv. Gerade wo worker versucht, die Kurve noch zu kriegen ...


Ich schlage vor, dass nur noch diejenigen weiter mitdiskutieren, die ein konstruktives Interesse an der Frage haben, warum man bei chmod(1) die Kombination aus `-R' und `/' verhindern oder nicht verhindern sollte.

Und bitte: In sachlichem und ruhigem Ton.

[NAB]

War's nicht? Genau danach hatte er doch gefragt. Aber gut, ich muss hier auch niemanden überzeugen

[worker]

Gerade wo worker versucht, die Kurve noch zu kriegen ...

Genau ... dann lösch doch diesen Thread einfach und keiner muss sich meine "Müllgedanken" ansehen ...
Danke und tschüss ..

[Meillo]

Geloescht wird (aus diesem Grund) sicher nicht. Viel eher wird das Thema mal ordentlich angepackt, auf dass ein Erfolg fuer alle raus komme. Hier mein Anfang:

chmod(1) ist in der gleichen Weise abgesichert oder nicht abgesichert wie chown(1) und rm(1): Das Rechtekonzept von Unix verhindert, dass schlimme Dinge passieren, weil das System auf diesem Weg vor normalen Usern geschuetzt ist.

Weil auch fuer normale User ein rekursives rm(1) sehr destruktiv sein kann, separiert rm(1) diesen Fall ueber einen separaten Switch (`-r'). Aehnlich separiert aber auch chmod(1) den rekursiven Fall (`-R') ... wobei, da ginge es nicht anders.

``rm -r /'' ist in etwa gleich schlimm wie ``chmod -R ... /'' ... bzw. gleich sicher, denn entweder hat man die Rechte dazu oder nicht. (Analoges gilt fuer die jeweils nicht-rekursiven Varianten: die sind beide aehnlich harmlos fuer Verzeichnisse.)

Wenn man `/' besonders behandeln wollen wuerde, dann muesste man das konsequenterweise in allen diesen Tools machen (und auch bei sowas wie ``find / -delete''). Das waere ganz schoen viel Aufwand ... aber mit welchem Erfolg? Sein System kann man weiterhin zerstoeren, denn ``chmod -R ... /etc'' oder /dev oder /usr/bin ist alles auch effektiv (und in der gleichen Weise wie das fuer rm(1) gilt ... und find(1)!). Zudem: Was ist mit ``/etc/../''? Man muesste also immer erst den Pfad aufloesen ... und zwar in jedem Tool! Denn der Systemcall muss die Aktion natuerlich grundsaetzlich erlauben.


Das Problem ist doch ein anderes: Die Inflation von root! Frueher ... in the good old days ... da war Unix noch ein Mehrbenutzersystem, also das System wurde von mehreren Usern genutzt. Damals waren die allermeisten selbstverstaendlich *nicht* root. Nur ganz wenige waren root und die arbeiteten auch nur selten als Superuser. Damals wurde noch soetwas genutzt was man Gruppen nennt. Aber heute liest ja jeder Logfiles als root statt sich zum Mitglied der Gruppe adm zu machen -- die Inflation von root eben. Vielleicht sind daran auch die Paketmanager schuld, denn weil die jeder auf seinem Einzelplatzrechner nutzen koennen will, ist jeder root und das dann auch fuer andere Dinge viel zu oft. Vielleicht waere es besser gewesen, die Distributionen haetten Wege gesucht, die Paketmanagernutzung fuer die Mitglieder einer Gruppe zu erlauben, dann koennte man grossteils root-frei auskommen und viele Gefahren waere gebannt.

25 Jahre lang war das alles bei Unix kein Problem, danach hat sich die typische Nutzung der Unix-Systeme veraendert. (Da spielt sicher auch eine Gewoehnung durch Windows-Erfahrungen mit rein ... die sie unter anderem auch in vermehrten Holzhammermethoden aeussern: ``Ich weiss zwar nicht wieso es als User nicht geht, aber als root geht's immer'' oder ``Mit chmod -R 777'' geht's immer -- sowas braucht man bei Unix fast nie.)

Die Moeglichkeit jederzeit problemlos Software installieren zu koennen hat aber auch ihren Preis. Aus grosser Macht folgt grosse Verantwortung ... und wenn wir jetzt oefter root sind, dann muessen wir oefter achtsam sein. Leider ist der Effekt gegenteilig: Je mehr wir root sind, desto achtloser werden wir. *Hier* liegt das Problem, nicht in den Sicherheitsmassnahmen in Tools. Fuer Sicherheitsmassnahmen gibt es bereits ein Mittel, und das heisst Berechtigungen. Wuerde man dieses wieder angemessen einsetzen, dann muesste man nicht unzaehlige Tools verkomplizieren und damit die wahren Werte von Unix -- naemlich seine Einfachheit und seine Orthogonalitaet -- opfern.


Ich hoffe, damit habe ich einige logische Erklaerungen geliefert.

[worker]

Ah ja, jetzt kommen wir der Sache näher.
Also ist das eher eine philosophische Sache - ausgehend von dem, dass man früher eher die Gruppen-Zugriffe genutzt hat, und heute sudoet sich mal rasch lieber jeder, als dass man sich zur entspr. Gruppe addet.

Aus dieser Sicht kann ich es nachvollziehen ... trotzdem frage ich mich dann, warum - wenn die Gruppen-Zugriffe nicht (mehr so oft) genutzt werden und die "root-Inflation" statt findet - die Tools nicht ebenfalls mit der Zeit mitgehen.

Ich habs ja schon mehrfach geschrieben hier, dass man selbst für die eigenen Fehler(/Dummheit) verantwortlich ist. Doch trotzdem kann ich das nicht unter einen Hut bringen, warum eine Philosophie dem Nutzen im Wege stehen soll. Ich kann mir wirklich nicht vorstellen, dass die Tools dermassen verkompliziert werden würden, wenn man die eine oder andere Sicherheitssperre (mit expliziter Umgehungsmöglichkeit) einbauen würde. Es ist doch ein Nutzen da, und Fehler wird man ohnehin machen, auch wenn man noch so sehr aufpasst.

Ein OS einfach und transparent zu halten ist natürlich wichtig, keine Frage. Doch nur wegen einer Philosophie, welche eh im Wandel steckt, grobe Schnitzer des Admins nicht aufzufangen halte ich für - sorry - nicht zeitgemäss.

Will hier nicht die Unix-Philosophie schlecht machen - ist halt einfach meine Meinung dazu.

Btw. solche Auffangroutinen müssen garnicht so komplex sein. Man kann doch einfach kurz die angegeben Optionen miteinander abgleichen und muss auch nicht zuerst irgendwelche Systemcalls aufrufen.

Aber wenn das halt "nur" eine Frage der Philosophie ist, dann kommen wir hier wohl nicht wirklich auf einen Nenner.

[uname]

Um das Thema zu vertiefen wäre interessant zu erfahren was das eigentliche Ziel deiner chmod-Aktion war. Sicher ist nur, dass bei Mehrbenutzer-UNIX-Systemen früher niemand auf die sinnfreie Idee gekommen wäre einem nichtpriviligierten Benutzer über /etc/sudoers einen vollständigen root-Zugriff zu geben. Denn dann ist klar, dass rm oder wie in diesem Fall chmod zu einem Problem wird. Durch diese Ubuntu-sudo-Konfiguration ist der Benutzer mit dem Voranstellen von sudo der Benutzer root.
Teste es aus:

Code: Alles auswählen

sudo whoami

sudo war mal dafür gedacht, dass man einzelne Befehle nutzen darf. Hier gehört z.B. nicht mal der Editor Vim dazu, da man aus diesem Editor per Shell ausbrechen kann. Man hat damit z.B. DAU-Benutzern erlaubt das System neu zu starten falls mal Wochende ist und der Admin nicht erreichbar ist. Auch praktisch um evtl. mal einen Webserver durchzustarten oder eine Script von root zu starten, welches z.B. Logverzeichnisse aufräumt usw.

Zurück zu deinem chmod. Entweder hätten deine Benutzerrechte so sein müssen, dass der betroffene Benutzer es ohne root selbst setzen kann oder dein Gruppenrechtekonzept war einfach nur falsch. Das legt man nämlich (als root) einmalig korrekt an und dann hat es zu funktionieren. Alle von root genutzten Scripte sollte gut durchdacht sein. Und dein sudo-Script zählte leider aufgrund der falschen sudoers-Konfiguration auch zu den root-Scripten. Und das war dein Problem.

[worker]

@uname:
Ich habe mir ein Script erstellt, welches mir Datei-/Verzeichnisrechte so setzt, wie ich sie brauche - hier in Verbindung damit, dass ich im Moment einen Samba-Dienst aufsetze.
Es geht hier jedoch nicht um Samba direkt, sondern z.B. um verschiedene Freigaben. Und da ich sowas nicht mehrmals machen will - falls mal was blödes passieren (z.B. beim Experimentieren) sollte und ich die Datei-/Verzeichnisrechte erneut setzen müsste, habe ich es halt gleich in nen Script gepackt, um es bei Bedarf einfach auszuführen.

Es geht ja eigentlich nur um einen dummen Fehler von mir, aber wem ist denn sowas nicht auch schon mal passiert?!
Ein "kleiner" dummer Fehler und das ganze OS ist unbrauchbar. Und ja, es ist unbrauchbar, auch wenn man hier was anderes erzählt, denn auch wenn man nur noch als root arbeiten kann, gibt es Dienste, die können bzw. dürfen nicht als root laufen. Abgesehen davon, wenn man mehrere User eingerichtet hat, etc.

Edit: Es ist eine Serverkiste, kein Laptop, etc. - nur zur Info. Hab ich ja nicht erwähnt..

[uname]

Drei Tipps für die Zukunft:

a.) wenn schon root was ausführen soll oder muss dann das Script für root schreiben (Ordner wäre /usr/local/sbin )
b.) den Pfad so weit wie möglich fest vorgeben, evtl. mehrere Scripte nutzen (/usr/local/sbin/samba-chmod , /usr/local/sbin/apache-chmod, ...)
c.) sudo nur sinnvoll einsetzen, der Benutzer könnte z.B. für "sudo /usr/local/sbin/samba-chmod" berechtigt werden (nicht für sudo gesamt)

Wenn du aber sowieso öfter als root arbeitest kannst du das Script auch als root direkt ausführen.
Aber die Idee überhaupt ein Script zu verwenden war schon nicht schlecht. Denn Scripte führen meist zu weniger Fehler als die direkte Eingabe von Befehlsketten.

[worker]

Das ist schon klar ^^

Wenn du aber im Script die Pfade per Variable setzt und hinterher dich bei der Variable vertippst (also ist da kein Pfad, sondern nur "leerer String") und auch noch so dumm bist (nicht du, ich! ) und hinterher nen Slash machst .......

Frag mich bitte nicht warum der Slash dahinter ....... k.a., war wohl iwie abgelenkt oder sonst was ...

[uname]

Keine Variable im Script. Im Script würde auch stehen:
/usr/local/sbin/samba-chmod

Code: Alles auswählen

...
chmod -R /pfad/nach/samba/
...

Der / am Ende war dumm. Aber auch ohne Slash hätte es "kleinere" Probleme geben können wenn auch vielleicht nicht in diesem Fall.
Ist natürlich klar, dass man das Script trotzdem auf einem Testsystem ausgiebig testet