Hallo an die Biertrinker!

Ich gedenke, mich mit homebrew auseinanderzusetzen. Das dürften einige von Euch ja schon hinter sich haben. Ich hab da ein paar Fragen:

1) Kann ich homebrew "ohne weiteres" auf mein MBP M1 installieren - /opt ist vorhanden, aber leer, wohl, da ich einen Installationsversuch abgebrochen habe -, so dass es aller Voraussicht nach 1) keine Probleme verursacht und 2) ggf. rückstandsfrei zu deinstallieren ist.
2) Ginge das auch mit einem MBP 2020 Intel, wenn im /usr... schon einiges installiert ist.
3) Wenn homebrew und auch php dann installiert ist, wie bringe ich apache bei, dass dann die homebrew-Version von php zu verwenden ist.
4) Homebrew meint, man "benötige" mind. Mojave für optimalen support. Ginge eine Installation auch unter Sierra? Hat da wer Erfahrung?
5) Gibt es irgendwo eine schöne Anleitung, wie php unter homebrew zu installieren und lauffähig zu machen ist. Auf der homebrew-Seite selbst habe ich schon gestöbert, jedoch nicht "das richtige" gefunden.

Dasselbe Problem.

Du nimmst jetzt aber auch an, dass die Nutzerrechte die einzige Sicherheitseinrichtungen ist. Es gibt ja nicht den Wachhund im Vorgarten "XProtect" (Dieser Virenscanner und die verschlossene Gartentür den Gatekeeper. Ich finde deine Hinweise zur Sicherheit ja gut und sie schärfen auch das Bewusstsein für die Problematik, jedoch sehe ich nicht unbedingt größere Probleme wie bei jedem anderen Programm, welches ich über das Internet laden.
Das sich solche Tools verbreiten konnten ist auch Apples schuld. Wie lange ist Apple mit veralteten PHP, Python, Java, Perl, Apache Versionen, etc. unterwegs gewesen und hat sich einen Scheiß um Sicherheit gekümmert. Und wenn man dann selbst die Versionen aktualisiert hat, ist die Hälfte zusammengebrochen (Wikis, Profilmanager, Websharing)

Tools wie Homebrew, MacPorts usw. sind ja nun auch kein Mainstream. Und wenn es jemanden dann trifft, dann sind diese Personen sicher auch in der Lage ihr System neu aufzusetzen. Lernen durch Schmerz, denn schließlich wollen wir uns ja auch nicht bevormunden lassen seitens Apple.

Nö, im Gegenteil: Ich habe ja gerade darauf hingewiesen, dass Nutzerrechte prinzipbedingt einen spezifischen Nutzer niemals daran hindern können, sich selbst zu schaden.

Ich nehme daher an, dass es einer Kombination verschiedener Schutzmechanismen bedarf und keine mit Hinweis auf die anderen vernachlässigt werden darf.
Ja, aber auch von einer Nischen-App würde ich verlangen, so bugfrei wie möglich zu sein.

Die Homebrew-Macher haben aus meiner Sicht mit dieser Designentscheidung ihre Inkompetenz so deutlich demonstriert, dass ihr Produkt damit indiskutabel geworden ist. Die Entscheidung geschah ja nicht aus Zwang; MacPorts zeigt, dass es auch anders geht (mal dahingestellt, ob es dort optimal gelöst ist).

Hat wohl auch kein Zweck.
Ich habe MacPort mal ausprobiert und fand es nicht so easy zu nutzen wie das.
Ein PHP von Hand installieren ist genauso wie Homebrew oder MacPorts. Gerade wenn man keine Ahnung hat kann man schnell ein falsches Skript auswählen.

Ja, natürlich nicht. Einfache Nutzung und Sicherheitsvorkehrungen arbeiten immer gegeneinander.

Wenn Du Deine Wohnungstür offenlässt, kommst Du auch einfacher in Deine Wohnung, als wenn Du sie erst aufschließen musst.

Ich habe diesen Thread mit viel Interesse verfolgt. So beeindruckend der Sachverstand der Teilnehmer auch ist, beeindruckender war für mich aber der jederzeit sachliche Tonfall derjenigen, die diesen Thread fachlich/sachlich getragen haben.
Ich habe meinen Wechsel von Windows zu macOS erst vor wenigen Jahren vollzogen und gehöre schon zur älteren (wer kennt noch Multiplan?) aber technisch immer noch interessierten Generation. In den ersten 2-3 Jahren war die Website von MacMark immer meine erste Anlaufstelle für technische Fragen rund um macOS. Bekannterweise ja auch in Sachen Homebrew...das ich dann nicht installiert habe.

Leider aber hat MacMark schon vor längerer Zeit aufgehört seine "daily outs" weiter zu bestücken. Ich fände es toll wenn einige der Threadteilnehmer mal darüber nachdenken würden sich zusammen zu tun um einen gemeinsamen technischen Blog zum Thema Unix/macOS usw. aufmachen würden. Ich bin sicher es gibt sehr viele interessierte Nutzer die einen solchen Blog sofort abonnieren würden.

Gruß chuby

Man kann jetzt darüber streiten, ob Paketmanager wie MacPorts oder Homebrew etwas ist, an dessen Existenz Apple schuld ist (in gewisser Weise ja, denn Apple hätte ja auch einen eigenen entsprechenden Mechanismus ins System hätte einbauen können), oder ob der Bedarf einer Minderheit der Nutzer den Aufwand der systematischen und zeitnahen Pflege Hunderter bis Tausender Pakete gar nicht rechtfertigt (vermutlich auch korrekt) und damit die Entscheidung, diesen Projekten das Feld zu überlassen, richtig und nachvollziehbar ist.

Und was bei dieser unterm Strich durchaus wichtigen Diskussion bislang gar nicht erwähnt wurde: "Best practice" ist nun mal die Arbeit unter einem unprivilegierten Benutzer (sprich: Nicht-Admin), während die Systempflege unter einem Administrator-Account erfolgt. Und daher ist es auch nur konsequent, die Installation von Paketen als Administrator vorzunehmen und die Nutzung dann als unprivilegierter Benutzer. Damit gehören die Homebrew-Pakete immer noch nicht root, sondern besagtem Administrator, sind aber vom unprivilegierten Benutzer genausowenig zu beschreiben wie der Rest des Dateibaumes.

Was die vielfach kritisierte Entscheidung der Homebrew-Entwickler angeht, den Installationsbaum für den installierenden Benutzer beschreibbar zu machen: Auch die sudo-Methode bei MacPorts hat sicherheitstechnisch ihre Nachteile. Während Homebrew einen Teil des Dateisystems für einen (im besten Fall administrativen) Benutzer öffnet, führt MacPorts beim Build ggf. ziemlich komplexe Makefiles mit sudo-Rechten aus. Hand aufs Herz: Wer liest die Dinger vorher?

Und dann kommt noch ein Grund hinzu, der mich immer schon trotz mehrfacher Anläufe, es zu nutzen, von MacPorts abgeschreckt hat: Die Dependency-Verwaltung bei MacPorts ist ein eher unerquickliches Thema. Wenn man sich z.B. mal die Dependencies des git-Pakets in Homebrew anschaut, dann ist die Liste recht übersichtlich:

Das gleiche bei MacPorts:

Mal abgesehen davon, daß es unnötig langsam und platzraubend ist, daß MacPorts meint, auch Pakete, die schon in geeigneten Versionen im System vorhanden sind, unbedingt nochmal als Depencency installieren zu müssen, ist natürlich auch jedes zusätzliche installierte Paket eines, das weitere Sicherheitslücken aufreißen könnte. Besonders, wenn die Installation unter sudo läuft. Mal ganz davon abgesehen, daß man es spätestens dann verflucht, wenn sich die Dependencies zweier Pakete beißen, was allein schon aufgrund der viel geringeren Anzahl bei Homebrew extrem selten ist.

Wie dem auch sei: Einen Tod stirbt man immer, und mir persönlich gefällt der Ansatz von Homebrew besser als der von MacPorts. Das letzte Restchen an Sicherheitsrisiko läßt sich nie ausschließen, ich halte die Risiken im Fall von Homebrew aber für besser handhabbar (siehe oben: Installation als Admin, Nutzung als einfacher User) als bei MacPorts (Installation läuft immer mit sudo, also als Admin und zusätzlich mit Root-Rechten per sudo). Und letztlich muß man auch immer noch den Paketen selbst vertrauen, was ich für das größere Risiko als beide Installationsstrategien zusammen halte - da herrscht Gleichstand.

Und nein, viel besser ist der Selbstbau der Pakete und die Installation per "sudo make install" diesbezüglich auch nicht, und am allerwenigsten, wenn man die Makefiles nicht vorher liest und versteht. Dafür ist es komplexer, dauert sehr viel länger und bietet auch ansonsten mannigfaltige Möglichkeiten, sich in den Fuß zu schießen. Ich habe diese Art der Selbstkasteiung vor vielen Jahren aufgegeben.

Wie gesagt: Ich will hier nicht den einen Paketmanager als den allein seligmachenden und den anderen als Teufelszeug darstellen. Beide haben ihre Daseinsberechtigung (fink gibt es auch noch, habe ich gerade gesehen, aber der unterstützt bislang nicht einmal Big Sur), beide haben ihre Vor- und Nachteile, und beide eröffnen die eine oder andere Lücke im System. Caveat emptor, gesunder Menschenverstand ist nicht zu ersetzen.

Ich glaube nicht, daß der Unterschied zwischen "brew install git" und "sudo port install git" jetzt den großen Unterschied im Handling ausmacht.

Die Problematik bei MacPorts liegt eher nicht beim erforderlichen "sudo", sondern bei der unerfreulichen Handhabung von Dependencies. Siehe oben.
Auch dieser Vergleich ist - ebenfalls siehe oben - nicht wirklich zutreffend. Du mußt die Tür durchaus nicht offen stehenlassen, und solltest das auch nicht tun - bei MacPorts muß ich jedem Paketboten explizit per sudo den Generalschlüssel fürs ganze Haus in die Hand drücken, während ich meine Pakete bei Homebrew als Admin-User selbst in die Wohnung tragen muß.

Beides funktioniert nur, wenn ich als Admin-User eingeloggt bin, es sei denn, ich war blöd genug, meine Homebrew-Installation in /usr/local unter einem nicht-administrativen Benutzer vorzunehmen. In dem Fall, den man übrigens gar nicht so einfach hinbekommt, ist man allerdings selbst schuld und hat die Schußverletzungen im Fuß verdient.

Daß die Homebrew-Doku in mancherlei Hinsicht zu stark die Simplizität und zu wenig die Sicherheit betont, sei definitiv bestätigt - das fängt schon bei diesem unvergleichlich dämlichen "/bin/bash -c $(curl ...)"-Kommando an. Wer sowas schreibt, gehört geteert und gefedert.

Nö, das wohl kaum. Ich hatte tjost so verstanden, dass er das nicht auf die einmalige Installation bezieht, sondern auf die kontinuierliche Nutzung, wo er bei Homebrew jederzeit was ändern kann, ohne sich mit Nutzerrechten herumschlagen zu müssen, wobei …… er sudo ja als „Hack“ empfindet.
Das bekommt man offenbar spielend einfach hin. Ein paar Nutzer haben doch jetzt via Terminal ihre Zugriffsrechte hier gepostet. Dem Namen nach zu urteilen war das in jedem einzelnen Fall der reguläre Nutzer, auf den Homebrew umgestellt wurde. Die allermeisten Mac-Nutzer legen doch nicht einmal einen eigenen Admin-Nutzer an, sondern geben ihrem regulären Nutzerkonto Admin-Rechte (tjost hat das oben explizit als Normalfall beschrieben). Dass jemand in macOS einen eigenen Admin-Nutzer anlegt, darfst Du glaube ich getrost zu den geekigen Ausnahmen zählen. Wer sogar sowas tut, der (außer Dir 😜) installiert dann eh kein Homebrew …
Im Homebrew-Fall kann also jeder beliebige Prozess zu jeder beliebigen Zeit Böses anrichten, im MacPorts-Falle die MacPorts-Herausgeber bei der Installation. Wie Du diese beiden Risiken ähnlich hoch veranschlagen kannst, bleibt mir ein Rätsel. So gesehen ist dann ja jedes Mac-Programm, das via Installationsprogramm installiert werden muss, bereits eine Sicherheitslücke. Wer das befürchtet, kann sich eigentlich gleich die digitale Kugel geben …
Wäre mir, wenn ich nicht selbst installieren würde, mit Abstand der sympathische Ansatz aufgrund bewährter Tools wie dpkg und apt-get. Bzw. wenn man das Rad schon neu erfindet, dann verstehe ich nicht, warum man nicht einfach Apples Installationsprogramm dazu nutzt.

Mit würde zu Zeiten von 10.0 beigebracht, das man auf einem neuen System zuerst einen Admin Account anlegt, dann seinen normalen ohne Admin Rechte. So hab ich es gelernt und so wird es auf allen Rechnern seit x Jahren gehandhabt die ich betreuen dürfte. Es haben sich nur ganz wenige beschwert und die haben es dann eingesehen das es so doch sicherer sei

Nochmal zum Beispiel mit dem ls-Befehl. Ganz unabhängig von Homebrew und Co. lässt sich dieser doch einfach mit dem Kommando alias auf ein neues Kommando umbiegen, sofern man .bashrc oder .zshrc nicht explizit geschützt hat. Auch das Terminal kennt Profile, die sich mit Nutzerrechten modifizieren lassen.


Und wer das Terminal infiltrieren will, macht das zuverlässiger (ohne auf Hombrew hoffen zu müssen) in Huckepack mit anderer Software, bei der man das Admin-Kennwort sowieso eingeben muss. Da gibt's reichlich Installationspakete oder Tools wie TinkerTool, SoundSource, BetterTouchTool, MS Teams, Zoom oder GOG bei denen man an irgend einer Stelle das Admin-Kennwort eingeben muss.

Und mit kann man doch deutlich mehr Schaden anrichten als mit , wenn XYZ bei der Installation noch Schabernack treibt.

Ja, und das ist ja auch genau richtig so.

Aber nicht alle haben das Glück, von Dir betreut zu werden.

Aber wiederum nur für das eigene Nutzerkonto. Nochmal: Vor Schaden im eigenen Nutzerkonto können Zugriffsrechte prinzipbedingt nicht schützen.

Aber ich verstehe die gesamte Stoßrichtung des Arguments nicht. Natürlich gibt es verschiedene Angriffsmöglichkeiten auf ein System. Aber das kann doch nicht rechtfertigen, ohne jede Not eine weitere Angriffsmöglichkeit zu eröffnen. Homebrew hat einfach eine völlig unsinnige Designentscheidung getroffen – was ist das Motiv, die zu verteidigen?
Auch Homebrew wird zu Beginn root-Rechte brauchen, sonst könnte es den Eigentümer von /usr/local ja gar nicht ändern.

Und nochmals: Es geht nicht so sehr um Gefährdung in dem kurzen Moment der Installation, es geht um die kontinuierliche Zeitspanne der Nutzung danach. Ich kann mich nur wiederholen: Wenn Du die Programme, die Du installierst, selbst der Untat verdächtigst – dagegen ist keinerlei Kraut gewachsen, da kannst Du nur sorgfältig auswählen, was Du installierst und von wo. Wenn ein Programm, das mit root-Rechten installiert werden muss, Böses tun will, kann es das immer.

Das ist einfach nicht der Punkt hier. Der Punkt ist, ob Dein Mac nach Abschluss der Installation dauerhaft unsicherer ist als zuvor. Und bei Homebrew ist er das.

Aber ich wiederhole mich nur noch und klinke mich daher jetzt aus. Ich habe gesagt, was ich dazu sagen kann. Dass es Leute gibt, die auf Teufel komme raus offenkundig schlecht durchdachte Software verteidigen wollen, finde ich faszinierend, aber verstehen tue ich es nicht.

Vor Äonen habe ich mal über Uriah Heep gelesen:
Wer sie mag, der mag sie.
Wer Musik mag, der mag sie nicht.

In diesem Sinne:
Wer Homebrew installieren mag, der installiert es.
Wer seine Daten mag, der installiert es nicht.

@Weia falsch und noch mal falsch.

Von der Installation war nicht die Rede.Whatever.

Und das ist ja das Kernrisiko bei einem Computer, weshalb ich das Risiko mit Homebrew aufgebauscht finde.

Es geht vor allem darum, dass ich deine Gewichtung nicht nachvollziehen kann und warum MacPorts grundsätzlich besser sein soll.

Aber nur einmal und nicht ständig bei jedem nachinstallierten Paket oder Update.

Verstehe ich nicht. Unrat kommt vor allem durch Installationen auf mein System und das Ziel ist meist, möglichst viele Leute zu erreichen. Das Terminal engt die Zielgruppe schon arg ein. Ein ausgetauschtes "ls" oder "sudo" beeinträchtigt so gut wie keine GUI-Software. Außerdem kann ich (als Malware) ein Fake-ls auch in den Benutzerordner legen und diesen in den Pfad aufnehmen, ohne auf Homebrew warten zu müssen. Das Risiko, sich mit Homebrew oder MacPorts Schadware zu installieren halte ich für größer als die umgebogenen Zugriffsrechte.

Richtig und hier liefert MacPorts deutlich mehr Anlässe, dass man überhaupt etwas mit Root-Rechten tut.

Genau das ist doch die Diskussion. Pauschal ist er das nicht, wenn man mit einem getrennten Admin-Account arbeitet, der sowieso zu empfehlen ist. Da ist man mit Homebrew nicht unsicherer unterwegs, eher im Gegenteil (siehe oben)

Vielleicht sollte man die Absolutheitsansprüche in dieser Diskussion lassen (mich eingeschlossen). Offenbar haben beide Ansätze je nach Ausgangslage ihre Berechtigung und jeweils ihre Nachteile.

Drei Aspekte möchte ich als Homebrew-Nutzer seit beinahe zwei Jahren noch einwerfen, die bisher nicht in der Diskussion vorkamen.

Erstens erlaubt Homebrew über das Cask-System auch die Installation und Aktualisierung von Apps. Auf diesem Weg halte ich Programme auf neuestem Stand, die nicht aus dem App Store stammen, und ohne dass ich sie starten muss. Für mich ein Komfortgewinn – und vielleicht sogar ein Pluspunkt in Sachen Sicherheit.

Zweitens habe ich über das zusätzliche Tap (=Repository) "cask-fonts" Zugriff auf eine Menge lizenzfreier Schriften, die mir Homebrew nicht nur installiert, sondern auch aktualisiert. Denn auch bei Fonts kann es Updates geben, und die manuell aktuell zu halten ist unter macOS doch eher anstrengend.

Drittens ist von den drei erwähnten Systemen (fink, macports, homebrew) der Homebrew-Paketmanager derjenige mit der aktivsten Community, was Entwicklung, Paketangebot und Nutzung angeht. Und zwar mit einem deutlichen Abstand.

Diese drei Features mag jede:r auf die eigene Weise bewerten in Bezug auf Sicherheit und Komfort. Aber ich wollte sie hier wenigstens mal erwähnt sehen.

Ich nutze ungoogled chromium (Chrome Browser ohne Google-Bestandteile, Github-Link: ), um die Installation von MS Teams etc. zu vermeiden.

Wie dem auch sei, da ich keine Ahnung habe, wie ich so ein Github-Paket installieren soll, habe ich ein fertiges Paket genommen. Nur aus irgendwelchen Quellen etwas installieren, ist ja nun auch so eine Sache

Aber auf Github wird auf eine homebrew-Installation verwiesen.

Wo kann ich mich informieren, wie ich so ein Github-Paket installiere?

"Github-Pakete" gibt es nicht.

Github ist dem Wesen nach eine Entwicklerplattform zum Verwalten von Sourcecode-Repositories. Es stellt auch einige Dienste darüber hinaus bereit (CI etc.), aber ein Paketmanager gehört nicht dazu.

Ob und in welcher Art es die Binaries zu den in Github verwalteten Sourcen gibt ist meist dem Readme-File zu entnehmen, so z.B. auch bei Eloston/ungoogled-chromium: . Dort findet sich ein Download-Link für Installer und auch der Verweis auf die homebrew-Cask "eloston-chromium". Ansonsten sind viele der auf Github verwalteten Programme halt über den jeweiligen Paketmanager (yum/rpm, apt/dpkg, ports etc.) der Zielsysteme oder third-party-Repository-Systeme (CPAN, PyPi etc.) verfügbar, wenn auch längst nicht alle.

Unter dem Download-Link auf Github, den Du verlinkt hast, finden sich auch MD5/SHA-Hashes, mit denen Du die Installer validieren kannst, wenn Du der Quelle, von der Du sie heruntergeladen hast, nicht vertraust.

Danke, "Binaries" meinte ich. Den Begriff hatte ich nicht parat.
Dann gehe ich mal dem Hinweis auf diesen Installer und der Validierung per Hashes nach.

Was mich an einer Homebrew-Installation nach dieser Diskussion zweifeln lässt, sind weniger die Sicherheitsbedenken, als dass eine Deinstallation für bleibende Veränderungen von Zugriffsrechten sorgt - ich kann also nicht vollständig den alten Zustand wiederherstellen.

Funktioniert, das habe ich auch eine Weile so gemacht. Es ist leider wirklich der einzige Weg, Teams-Konferenzen bei einem meiner Kunden nutzen zu können, ohne sich Google einzureißen - der dämliche Electron-basierte Teams-Client, den Microsoft da liefert, funktioniert nicht mal zur Anmeldung.
Das kann ich nachvollziehen, andererseits würde ich da schlicht und einfach mit einem freundlichen
Fakten schaffen, wenn sich die Notwendigkeit ergäbe.

Habe ich gerade mal spaßeshalber gemacht: Danach mault (erwartungsgemäß) Homebrew beim Versuch, etwas neu zu installieren, aber das war's auch. Dabei liefert dann "brew doctor" auch eine schöne Liste von Verzeichnissen, auf die Homebrew Schreibrechte braucht:

Die Vorstellung, man könne nach der Installation von irgendetwas den Urzustand des Systems wiederherstellen, ist ohnehin eine sehr idealisierte und realitätsferne (und in manchen Fällen auch gar nicht wünschenswert).

Dafür gibt es eigentlich nur einen Weg: Ein gutes Backup.

Von dieser idealen Vorstellung mag ich mich aber wirklich nicht trennen Ich räume immer pingelig alle Spuren von Programmen auf.

Ließe sich der Zugriff auf das Verzeichnis immer bei Bedarf ein- und auschalten, wenn ich doch ein weiteres Programm per homebrew installieren möchte?
Oder anders gefragt, wie laut das Einschalt-Gegenstück von sudo chown -R root:wheel /usr/local?

Electron ist bei mir ein guter Grund mich von Programmen zu trennen. Aufgebläht und un-Mac-like. Diese Programme können dann besser per ungoogled-Chromium aufgerufen werden.

Oje ... wenn Du mal sehr viel Zeit hast, dann installiere Dir Tripwire und laß Dich davon überraschen, wie weit Du von Deinem Ziel entfernt bist ...

Ich kann Deinen Ansatz aber gut verstehen, und für meine Server, derer ich etliche betreibe, habe ich eine entsprechende Strategie - die aber leider bei Desktop-Systemen schnell an ihre Grenzen stößt:

• Alle Server werden von Basisinstallationen ausgehend vollständig automatisiert aufgesetzt (eine Kombination aus virt-install und Ansible mit entsprechenden maßgeschneiderten Playbooks). Manuelle Änderungen gibt es nicht.
• Datenverzeichnisse liegen separat und sind auch das einzige, was der Datensicherung unterliegt (was unglaublich viel Platz spart, das nur nebenbei).
• Wenn ein Server aus irgendwelchen Gründen "zickt" (passiert eigentlich nie, aber just in case), wird die VM gelöscht und neu aufgesetzt.

Und nicht einmal diese eher aufwendige Methode stellt sicher, daß ein Ausgangszustand genau wiederhergestellt werden kann. Pakete ändern sich (gut, das bekommt man auch noch mit einem eigenen, statischen Repository in den Griff), und die Installation von Paket x in Version 1.2.3 hat in der Regel einen anderen Systemzustand zur Folge als die Installation von 1.2.2 und danach der Upgrade auf 1.2.3. Das macht in der Regel nichts aus, aber der theoretische Idealfall von identischen System ist es auch nicht.
Die eine Möglichkeit ist natürlich die Ausführung des von Homebrew unter "brew doctor" ausgegebenen Kommandos. Danach geht es wieder. Das ist vermutlich am nächsten an Deinem Ideal gelegen, aber es kostet halt relativ viel Zeit beim Hin- und Herschalten.

Oder, vereinfacht, wenn auch nicht identisch im Effekt:
und danach wieder zurück auf root:wheel.

Ich würde allerdings dennoch eher einen Admin-User für die Paketinstallation und -pflege verwenden und dem dauerhaft die Rechte auf /usr/local einräumen. Der alte Kompromiß zwischen maximaler Sicherheit und akzeptabler Nutzbarkeit ... aber klar, jeder zieht die Grenze hier anders.

Es soll auch Leute geben, die sudo vorziehen aber root nach alter Unix-Väter Sitte allmächtig sein lassen - ergo pauschal AppArmour/SELinux/SIP etc. abschalten. Das ist wieder ein Loch, das ich definitiv nicht aufrisse. sudo ist ein starkes Tool und in kundiger Hand auch ein Sicherheitsgewinn, aber wie immer muß man sehen, wo die Grenzen sind. Und sudo ohne geeignete Einschränkungen mit fremden Code nutzen ist eine ziemlich riskante Vorgehensweise.

@Weia, lass es einfach bleiben. Diskutiere da mit anderen drüber aber lasse mich aus Deiner Argumentationskette bitte heraus oder kläre das mit mir durch eine PM das hat hier nichts zu suchen.

Nun, ich muss auch wissen, wo meine eigenen Grenzen sind - ich meine im Hantieren mit "sudo". Mich also auf Gefundene Kommandos im Web zu verlassen ist auch nicht die Lösung.

Immerhin, Punkt 2 separate Datenverzeichnisse ziehe ich konsequent durch und sichere diese auch entsprechend.

Deine späteren Ausführungen setzen vermutlich voraus, dass User-Account und Admin getrennt sind. Das ist bei mir noch nicht der Fall. Das sollte ich aber mal machen.
Ich denke mit dem Ein-/Ausschalten von root:wheel für homebrew bin ich schon einen Schritt weiter.

Text wird gesichert und nach und nach umgesetzt.

Definitiv nicht. Ich werde spätestens dann nervös, wenn jemand irgendwelche Scripte mit sudo ausführt - bei
weiß man relativ genau, was man tut. Bei
nicht.

Übrigens, wenn wir gerade beim Thema "sudo und Sicherheit" oder "Scripts und Sicherheit" sind: Es ist grundsätzlich anzuraten, die Kommandos bei sudo und in Scripts mit vollem Pfad anzugeben (und ja, ich lasse das in Forenbeiträgen auch oft aus Faulheit weg - aber nie in Scripts!). Also eigentlich wäre das korrekte Kommando:
Warum? Auf die Weise ist man sicher vor veränderten PATH-Werten und Aliases. Der Nachteil (und der Grund, warum man oft die Kommandos ohne Pfad in Forenbeiträgen findet): Man muß dann wissen, wo das jeweilige Kommando im Verzeichnisbaum steht. Und das muß nicht immer der gleiche Pfad sein.

Du willst nicht wissen, in wievielen Install-Scripten, Makefiles etc. ich diese Regel schon mißachtet gefunden habe. Mitunter wundert einen wirklich, daß nicht mehr schiefgeht. Die Dinger unter sudo auszuführen ist dann doppelt brisant, zumal sudo den PATH vom aufrufenden Prozeß erbt:
Will sagen: Wenn der PATH in Deiner aufrufenden Shell verbogen ist, ist er das unter sudo auch. Here be dragons.
Das ist, wie gesagt, der sicherste Weg.
Auch das funktioniert natürlich nur, wenn Du als administrativer User angemeldet bist.

Du hast mich direkt angesprochen:Darauf habe ich geantwortet. Das werde ich ja wohl noch dürfen. Aus meiner Sicht es sogar ein Gebot der Höflichkeit, das zu tun.

Im konkreten Fall hatte ich bereits in meinem Beitrag zuvor geschrieben, dass ich mich aus der weiteren Diskussion zurückziehen will und habe das nur aufgrund Deiner direkten Adressierung an mich durchbrochen.

Und das hältst Du mir jetzt vor? Sagenhaft.

Apropos Admin. Das schweift natürlich jetzt sehr vom Thema ab.
Bei einem Clean Install lege ich einen Admin- und einen User-Account an und arbeite mit dem User Account. So weit so klar.
Gibt es die Möglichkeit bei einem bestehenden System, den Admin-Account zu einem User-Account mit all seinen Einstellungen zu migrieren? Der Admin-Account sollte weitgehend blank sein also ohne Mail-Bibliothek usw., denn er dient schließlich nur der Administration.

Geht das evtl. mit Neuanlegen eines Admin und Downgrade alter Admin-Account?

Das müßte eigentlich mit dem "naiven" Ansatz gehen:

• Einen (zweiten) Admin-Account anlegen
• Ausloggen und auf diesen zweiten Admin-Account wechseln
• Den alten Account in den Benutzereinstellungen zu einem Standard-Account "degradieren"