staging.inyokaproject.org

Newubunti schrieb:

UlfZibis schrieb:

Newubunti schrieb:

sudo -H nano DATEI 

Für Nano braucht man doch die Option -H nicht. Warum führst Du gerade das als Beispiel an?

Das steht derzeit so als Beispiel im Artikel.

Das habe ich jetzt korrigiert, weil die Option -H an dieser Stelle völlig wirkungslos ist. Ihre Angabe schadet zwar i.d.F. wohl nicht, aber die Befehle sudo nano als auch sudo -H nano schreiben nach meinen Versuchen beide in das Benutzerverzeichnis von root und nicht in das Benutzerverzeichnis des Befehlsgebers.

Die mag daran liegen, dass nano selbst vielleicht einige Fehler nicht macht, die von Autoren anderer Editoren übersehen werden. Jedenfalls ist die Option -H von sudo weder ein Allheilmittel noch in allen Situationen erforderlich noch in allen Situationen sinnvoll noch immer unschädlich.

Der Artikel ist jetzt in der Baustelle.

UlfZibis schrieb:

Es wird aber immer wieder neue Nutzer geben, die der Versuchung sudo nautilus unterliegen werden, weil sie all das hier Vorgeschlagene zu aufwendig, kompliziert oder was auch immer finden. Dem könnte man mit der Empfehlung, statt dessen Nemo und das richtig zu nutzen, entgegenwirken.

Da würde ich dann eher einen non-invasiven Dateimanager vorschlagen der nicht mit irgendeinem DE verbandelt ist oder Abhängigkeiten dazu hat. Sprich keine GNOME/Plasma-Dependencies, etc. Warum hat tom³ erklärt.

Sich auf Dateimanager zu fokussieren finde ich auch an dieser Stelle falsch. Ich verwende gar keinen, bzw. ganz selten mal für Operationen die sonst zu unhandlich sind. Lenkt auch von sudo ab, welches wiederum vom Ziel des Artikels ablenkt.

Newubunti schrieb:

sudo -H nano DATEI 

Das steht derzeit so als Beispiel im Artikel.

Das kann auch korrekt (gewesen) sein und kommt ganz darauf an, wie sudo konfiguriert[1] ist. Das Tool kann vielleicht nicht so granuliert wie PolicyKit eingesetzt werden, ist aber alles andere als stumpf. Da müsste man alte und aktuelle Konfigurationen und Plugins (audit,noexec,…) vergleichen. Wie ich oben schon irgendwo schrieb, es ist auch möglich, das sudo und sudo -H gleich agieren, je nach Konfiguration.

Das wäre allerdings in der Artikeldiskussion zu sudo sinnvoller, als auf der hiesigen Abstraktionsebene.

• 1: /etc/sudo{.conf,ers}, /usr/lib/sudo/,…

ChickenLipsRfun2eat schrieb:

Was die grafische Umgebung angeht:

• GNOME: admin:///

• Plasma: Normal arbeiten, Anfrage kommt beim Speichern.

• sudoedit

Darauf sollte der sich beschränken.

Ja, und dabei bitte noch kurz erläutern ob

• admin:///

• sudoedit

genau gleich vorgehen, oder ob das eine oder andere - eventuell auch situationsbedingt - vorzuziehen ist.

Für „erweiterten Umgang mit Rootrechten“ kannst du ja deinen Unterartikel schreiben.

Da hast Du mich missverstanden, oder ich verstehe diesen Satz falsch. Ich will keinen erweiterten Umgang mit Rootrechten. Ich will als weiteren Artikel, eine bessere Erklärung zu der Thematik, denn auch jetzt wieder Deine Erklärungen sind mit zu abstrakt. Das soll übrigens kein Vorwurf sein!

Das war auch der Grund, warum ich weiter oben mit einem konkreten Beispiel arbeiten wollte, was leider mittlerweile wieder eingeschlafen ist.

Am liebsten wäre es mir - wobei ich mich mit Plasma in der Praxis nicht wirklich auskenne - wenn es bezüglich des Arbeitens an Dateien, deren Änderung Rootrechte erfordern, es so wäre wie unter Plasma - und zwar für alle Desktop-Umgebungen.

Unter Ubuntu Gnome besteht aus Anwendersicht z.B. das Problem, dass wenn ich mit gedit die Datei /etc/default/grub öffne und darin eine Änderung vornehme, ich in einer Sackgasse lande. Die Speichern-Schaltfläche ist schlicht nur ausgegraut. Das ist - auch aus sicherheitstechnischer Perspektive - schlechtes Systemdesign.

Gutes Systemdesign würde den Nutzer - unter Umständen ruhig auch doppelt - warnen, dass er jetzt eine Änderung an einer wichtigen Systemdatei vornimmt und dann das Passwort für einen Account, der dazu die Berechtigung hat, anfordern.

Stattdessen lässt man den Anwender an dieser Stelle allein, was dazu führt, dass er sich auf die Suche nach einer Lösung macht und machen muss.

Die Gefahr ist dabei groß, dass er dabei auf eine Informationsquelle stößt, die ihm - weil vielleicht auch einfach nur veraltet - zu sudo gedit oder sudo -H gedit rät. Der Charm aus Einsteigersicht von sudo gedit ist, dass es sich z.B. gegenüber VISUAL=gedit sudoedit noch mal eine Ecke leichter merken lässt.

Weil das so ist und weil wir das nicht ändern können, braucht es IMO diesen Artikel hier, wie er im Grunde jetzt ist, also mit einer möglichst glasklaren Handlungsanweisung für optimales Verhalten.

Weil diese Anweisungen hier dann aber schon auch irgendiwe bevormundend sind und eben im Widerspruch zu anderen Lösungswegen im Netz stehen können, wäre es - gerade bei einem Sicherheits-relevanten Thema - IMO auch sinnvoll, zu erklären warum das beschriebene Vorgehen in diesem Artikel vorzuziehen ist. Dabei aber dann bitte mich sachlichen Erklärungen ohne Panikmache.

Und noch mal ganz deutlich, diese Erklärungen sehe ich in einem eigenen Artikel, damit dieser hier in der Handlungsanweisung klar und verständlich bleibt.

LG, Newubunti

Newubunti schrieb:

Unter Ubuntu Gnome besteht aus Anwendersicht z.B. das Problem, dass wenn ich mit gedit die Datei /etc/default/grub öffne und darin eine Änderung vornehme, ich in einer Sackgasse lande. Die Speichern-Schaltfläche ist schlicht nur ausgegraut. Das ist - auch aus sicherheitstechnischer Perspektive - schlechtes Systemdesign.

Genau so sehe ich das auch. Und anmerken möchte ich zum 102-ten Mal, das Nemo das schon so macht.

Gutes Systemdesign würde den Nutzer - unter Umständen ruhig auch doppelt - warnen, dass er jetzt eine Änderung an einer wichtigen Systemdatei vornimmt und dann das Passwort für einen Account, der dazu die Berechtigung hat, anfordern.

Stattdessen lässt man den Anwender an dieser Stelle allein, was dazu führt, dass er sich auf die Suche nach einer Lösung macht und machen muss.

Die Gefahr ist dabei groß, dass er dabei auf eine Informationsquelle stößt, die ihm - weil vielleicht auch einfach nur veraltet - zu sudo gedit oder sudo -H gedit rät. Der Charm aus Einsteigersicht von sudo gedit ist, dass es sich z.B. gegenüber VISUAL=gedit sudoedit noch mal eine Ecke leichter merken lässt.

Weil das so ist und weil wir das nicht ändern können, braucht es IMO diesen Artikel hier, wie er im Grunde jetzt ist, also mit einer möglichst glasklaren Handlungsanweisung für optimales Verhalten.

Weil diese Anweisungen hier dann aber schon auch irgendiwe bevormundend sind und eben im Widerspruch zu anderen Lösungswegen im Netz stehen können, wäre es - gerade bei einem Sicherheits-relevanten Thema - IMO auch sinnvoll, zu erklären warum das beschriebene Vorgehen in diesem Artikel vorzuziehen ist. Dabei aber dann bitte mich sachlichen Erklärungen ohne Panikmache.

100 % Zustimmung !

Und noch mal ganz deutlich, diese Erklärungen sehe ich in einem eigenen Artikel, damit dieser hier in der Handlungsanweisung klar und verständlich bleibt.

Ich finde, Handlungsanweisungen und Erklärungen gehören in einen Artikel, letztere gerne in eigenem Abschnitt, sodass der Leser leichter selbst entscheiden kann, ob er sich das antut.

ChickenLipsRfun2eat schrieb:

Sich auf Dateimanager zu fokussieren finde ich auch an dieser Stelle falsch.

Muss auch nicht. Aber das Thema "Dateimanager unter Root-Rechten" hier ganz wegzulassen finde ich falsch. Wie gesagt, es geht ALLGEMEIN um "mit Root-Rechten ARBEITEN".

Ich verwende gar keinen, bzw. ganz selten mal für Operationen die sonst zu unhandlich sind. Lenkt auch von sudo ab, welches wiederum vom Ziel des Artikels ablenkt.

Ich dachte, der Artikel sollte Einsteiger-freundlich gehalten werden.

Newubunti schrieb:

Ja, und dabei bitte noch kurz erläutern ob

• admin:///

• sudoedit

genau gleich vorgehen, oder ob das eine oder andere - eventuell auch situationsbedingt - vorzuziehen ist.

Nein. Sudoedit nutzt wie der Name schon sagt sudo und auch dessen securiy policy (default:sudoers). GTK und Qt arbeiten mit PolicyKit, welches Aktionen und Regeln im XML-Format und JavaScript-Code anbietet. Aus Anwendersicht ist das aber egal, da beides darauf ausgelegt ist in einem engen, festgelegten Rahmen zu agieren. Und auch da kann man falsch mit umgehen, wenn man denn will 😉 pkexec gedit bspw. (Wobei ich nicht weiß wie das reagiert, da ich gedit hier nicht habe).

…denn auch jetzt wieder Deine Erklärungen sind mit zu abstrakt.

Du wirst kaum was nicht-abstraktes finden. Schau dir die polkit-Regeln mal an, schau dir die Möglichkeiten sudo mit Plugins mal an. Wie willst du das darstellen ohne Abstraktion? Rootrechte sind ja nur ein kleiner Teil. Dazu kommen weitere Abstraktionen durch sowas wie rkit (Kernel), AppArmor, DBus als „Wrapper“,…

Ich habe eine grobe Vorstellung davon (ohne AppArmor & Co) und auch schon PolicyKit-Regeln geschrieben. Trotzdem traue ich mir nicht zu das im Detail festzunageln, schon gar nicht unter inbezugnahme der grafischen Umgebung, die noch mal gefühlte drei Milliarden Abstraktionen draufpackt. Du kannst ja mal versuchen dich im Quellcode eines kleinen Projektes zurechtzufinden. Das ist kein „mal eben so“. Wenn du also konkrete Details willst, such dir ein Projekt raus und verfolge den exakten Weg, den es geht. Für den Anfang hilft dir vielleicht das weiter:

• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/desktop_migration_and_administration_guide/policykit

• https://www.mail-archive.com/polkit-devel@lists.freedesktop.org/msg00142.html

Das war auch der Grund, warum ich weiter oben mit einem konkreten Beispiel arbeiten wollte, was leider mittlerweile wieder eingeschlafen ist.

Eröffne einen separaten Thread und bring eine konkrete Fragestellung was genau du willst.

Am liebsten wäre es mir - wobei ich mich mit Plasma in der Praxis nicht wirklich auskenne - wenn es bezüglich des Arbeitens an Dateien, deren Änderung Rootrechte erfordern, es so wäre wie unter Plasma - und zwar für alle Desktop-Umgebungen.

Wie langweilig 😉 Wenn alle alles gleich machen, entfällt die Diversität. Aber du kannst dich ja ans GNOME-Projekt wenden und das anhand des grub-Beispiels erläutern. Vielleicht gibt es sowas auch schon. GNOME ist aus vielen Gründen nicht meine Wahl.

Weil diese Anweisungen hier dann aber schon auch irgendiwe bevormundend sind und eben im Widerspruch zu anderen Lösungswegen…

Haben wir hier doch schon alles erläutert. Ich glaube auch nicht, das sich der Großteil der Ubuntuianer dafür interessiert, wie die technischen Lösungen aussehen und wie man deren Zusammenspiel herausfinden kann. Es gibt sichere Wege, die man nutzen kann, aber auch sehr viele andere die funktionieren können. Das lässt sich nicht pauschal erschlagen. Wir empfehlen hier die von Ubuntu implementierten Wege über die o.g. Methoden. Das bedeutet keine starre Regel, nur nimmt dich keiner an die Hand, wenn du andere Wege gehst.

ChickenLipsRfun2eat schrieb:

... Vielleicht gibt es sowas auch schon. GNOME ist aus vielen Gründen nicht meine Wahl.

Interessant, und Nemo & Co. ist es ja auch nicht.
Darf ich mal neugierig fragen, mit was Du denn so arbeitest?

UlfZibis schrieb:

ChickenLipsRfun2eat schrieb:

... Vielleicht gibt es sowas auch schon. GNOME ist aus vielen Gründen nicht meine Wahl.

Interessant, und Nemo & Co. ist es ja auch nicht.
Darf ich mal neugierig fragen, mit was Du denn so arbeitest?

Das artet hier langsam in Richtung OT aus.

ChickenLipsRfun2eat schrieb:

Newubunti schrieb:

Ja, und dabei bitte noch kurz erläutern ob

• admin:///

• sudoedit

genau gleich vorgehen, oder ob das eine oder andere - eventuell auch situationsbedingt - vorzuziehen ist.

Nein. Sudoedit nutzt wie der Name schon sagt

Ok, offenbar habe ich zu ungenau gefragt.

• sudoedit verstehe ich (hoffentlich): Der Editor selbst wird nicht mit Rootrechten gestartet, die Rootrechte werden nur beim Schließen des Editors aufgerufen, um die Datei an ihre angestammte Postition im Dateisystembau schreiben zu können.

Macht das admin:/// im Prinzip genauso, oder läuft bei z.B. gedit admin:/// gedit mit Rootrechten? Insofern war meine Frage, ob sudoedit und addmin:/// das Gleiche - und wohlgemerkt das Gleiche und nicht das Selbe - machen zu verstehen. Denn der Link im Artikel auf https://wiki.gnome.org/Projects/gvfs ist da nicht wirklich hilfreich.

Da Du gesagt hast, dass Du gedit nicht vorliegen hast, setze anstelle von gedit einen grafischen Editor den Du vorliegen hast bzw. besser kennst - also sofern Du Dich in der Lage siehst die Frage zu beantworten.

Ich kann übrigens Quellcode nur sehr rudimentär lesen, weshalb ich das leider erfragen muss und nicht selbst nachschauen kann.

Ich verlange auch nicht, dass das eben mal so nebenbei beantwortet wird.

LG, Newubunti

Hallo,

Anmerkung zum Abschnitt "Dateien mit dem GVFS admin:// Protokoll öffnen". Da steht der Satz "GVFS ist standardmäßig bei Ubuntu installiert, kann aber unter allen Ubuntuderivaten nachträglich installiert werden. Weitere Informationen sind im Wikiartikel zu gio zu finden."

Da sind 1,5 Fehler drin. 1) ist GVFS (für Jammy) nicht nur für Ubuntu OOTB installiert, sondern auch bei Xubuntu, Ubuntu Mate, Ubuntu Budgie und Lubuntu. Und bei Kubuntu halt nicht.

Habe es bei für Kubuntu (bei einer Instanz in Multipass) nachinstalliert. Der zusätzlich verbrauchte Plattenplatz ist sehr moderat (12 MB), aber GVFS funktioniert nicht im Zusammenspiel mit Kubuntu (was ich jetzt nicht so überraschend finde...). Wenn man kate admin:///etc/fstab aufruft, dann meldet Kate "unbekanntes Protokoll admin" und im Terminal erscheint noch eine Fehlermeldung von kf.kio.core.

Gruß, noisefloor

Newubunti schrieb:

Macht das admin:/// im Prinzip genauso, oder läuft bei z.B. gedit admin:/// gedit mit Rootrechten? Insofern war meine Frage, ob sudoedit und addmin:/// das Gleiche - und wohlgemerkt das Gleiche und nicht das Selbe - machen zu verstehen. Denn der Link im Artikel auf https://wiki.gnome.org/Projects/gvfs ist da nicht wirklich hilfreich.

Nein, das sind unterschiedliche Techniken. Bei PolicyKit wird für gewöhnlich der Teil des Programms das erweiterte Rechte benötigt wird ausgelagert und über die Aktionen und Regeln der Zugriff definiert. Das kann auch über DBus funktionieren, Hauptsache das Programm hat eine Abstraktion die mit unterschiedlichen Rechten umgehen kann. sudo ist eher das scharfe Messer, PolicyKit das Skalpell. Dabei kommt es auch darauf an, was genau das Programm macht. Es gibt keine garantierte 1:1-Übersetzung welche Regel bspw. für das Formatieren einer Partition angewendet wird, dein Tool schickt einfach einen Request an die DBus-API, diese fordert entsprechende Passwörter ein und meldet dann Erfolg oder Misserfolg zurück. Da steht also ein ganzer Apparat an Mechanismen hintendran die mit Standardregeln, speziellen Regeln und diversen Aktionen einen Weg suchen.

gedit läuft mit Rootrechten, wenn du pkexec gedit aufrufst und das nicht von vordefinierten Regeln verhindert wird. Da gilt dann aber auch das selbe wie für sudo gedit. In der primitivsten Form sind die theoretisch gleich und führen das Programm stur als root aus. Praktisch wird das nicht stimmen, da sudo immer mit vordefinierten Plugins kommt und PolicyKit mit Standardregeln.

noisefloor schrieb:

… kate admin:///etc/fstab aufruft, dann meldet Kate "unbekanntes Protokoll admin" und im Terminal erscheint noch eine Fehlermeldung von kf.kio.core.

Kann auch nicht funktionieren, da es kein kio-plugin für gvfs gibt (zumindest kenne ich keins). kio funktioniert völlig anders als gvfs, klassische fuse-mounts, etc. Unter Kate reicht kate /etc/fstab aus. Du kannst die Datei dann bearbeiten und beim Abspeichern poppt PolKit mit der Berechtigungsanfrage auf.

Du könntest natürlich gvfs trotzdem parallel nutzen, dann aber mit GTK-Programmen. Eventuell gibt es da auch Möglicheiten mit xdg-desktop-portal-{gnome,kde}, weiß ich nicht.

Hallo,

Unter Kate reicht kate /etc/fstab aus. Du kannst die Datei dann bearbeiten und beim Abspeichern poppt PolKit mit der Berechtigungsanfrage auf.

Kann ich nicht bestätigen. Kate behauptet das zwar, wenn man sudo kate ausführen will. Aber wenn ich z.B. kate /etc/fstab ausführe öffnet sich die Datei in Kate - aber beim Speichern kommt eine Fehlermeldung bzgl. fehlender Rechte und keine Passwortabfrage.

Wobei ich nicht behaupten würde, dass meine Testinstallation repräsentativ ist. Ist ein Multipass Instanz von der Grundinstallation von Ubuntu (ohne DE) und dann die DE nach installiert, siehe Baustelle/Howto/Multipass Instanz mit GUI.

Wenn Nutzer mit einer "richtigen" Kubuntuinstallation bestätigten können, dass das so funktioniert, dann passt es ja.

Gruß, noisefloor

noisefloor schrieb:

Unter Kate reicht kate /etc/fstab aus. Du kannst die Datei dann bearbeiten und beim Abspeichern poppt PolKit mit der Berechtigungsanfrage auf.

Kann ich nicht bestätigen. Kate behauptet das zwar, wenn man sudo kate ausführen will. Aber wenn ich z.B. kate /etc/fstab ausführe öffnet sich die Datei in Kate - aber beim Speichern kommt eine Fehlermeldung bzgl. fehlender Rechte und keine Passwortabfrage.

Och wie schade. Ich dachte, das wäre der Anfang, für sinnvoll ausgestattete Text-Editoren.

noisefloor schrieb:

Kann ich nicht bestätigen…

Versuche es mit nem neuen Nutzer oder debugge PolKit. Ich nehme mal an, das sich dort die Regeln vermischen. Bei mir kommt da allerdings nur

[~]› G_MESSAGES_DEBUG=all kate
# … Qt-Meldungen
(kate:47931): GLib-GIO-DEBUG: 13:23:54.215: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)

da es funktioniert. Vielleicht hast du mehr Glück. Ansonsten musst du wohl polkitd im Auge behalten.

Da das nachinstallieren von Plasma in Ubuntu historisch schon immer etwas war, wovon abgeraten wurde, würde ich aber auch darauf tippen, dass es bei einer nativen Installation funktioniert.

Hallo,

ich mache dazu vielleicht mal eine separaten Thread im Supportforum auf. So rein Interesse halber bzgl. Multipass. Hat ja mit der Baustelle hier höchstens mittelbar was zu tun.

Gruß, noisefloor