ubuntuusers.de

Die Frage hierzu ist, was standardmässig mitgeliefert wird. Das weiß ich allerdings auch nicht. ich weiß nur, dass dpkg ab und zu Processing triggers for AppArmor und Profiländerungen dafür macht. Das müsste man dann entsprechend recherchieren...

Ubuntu enthält einen kleinen Regelsatz von Haus aus, weitere sind über appamor-profiles verfügbar. 😉 Mehr dazu

redknight schrieb:

user unknown schrieb:

Also wenn der unbedarfte User nicht chmod (rekursiv?) auf / anwendet, sondern auf ~, ist der Schaden dann geringer? Welche Verwendung von chmod ist das, die durch die sudo-Technik verhindert wird? Wieso soll er nicht sudo chmod machen, wenn er permission denied erhält?

Ich suche die Threads gern raus, wir hatten in meiner (relativ kurzen) Zeit als supporter mehrere Helden, die chmod rekursiv auf / angewendet haben und danach Systemdienste nicht mehr starteten, weil die Rechte der zugehörigen Konfigdatei überprüft wurden und nicht in Ordnung waren. UNd noch einmal doppelt so viele, die genau das vorhatten und nur von Permission denied genau daran gehindert wurden.

Nicht raussuchen, ich glaube Dir das schon.

Nur nochmal zurück zur Einordnung in die Diskussion, wo es mehrere Tipps gab. Ich empfehle ja beileibe nicht sich mit rootaccount anzumelden.

Wer unbedingt will, der zerschießt sein System auch mit sudo.

Wer ein mit sudo gestartetes Programm weiter offen hat, der ist nur dann gefährdet, wenn dies eine Rootshell ist. Der sollte sich also eher ausloggen? Aber wenn er innert 15 Minuten sein chmod macht, dann kracht es auch.

Hallo,

ich verstehe das mit AppArmor und sudo nicht... AppArmor soll verhindern, dass bestimmte Prozesse nur auf für sie bestimmte Ressourccen (Verzeichnisse etc.) zugreifen können und nicht "Amok laufen". Das wird von AppArmor überwacht.

Mit sudo hat das nix zu tun...

Gruß, noisefloor

appamor stand, und steht derzeit auch gar nicht im Artikel !?!

So kommen wir nicht weiter. Ich denke, mittlerweile ist uns allen klar, das sudo in erster Linie dazu da ist, keinen Unsinn mit den Systemdateien zu machen, solange man nicht genau weiß, was man da tut. Alle anderen Sicherheitsbezogenen Dinge sind in dem Artikel überflüssig. Mein Vorschlag wäre daher:

• Kurze(!) Einleitung das "Root werden" in erster Linie .... s.o.

• Kurze Erklärung ROOT → [Baustelle/sudo#Root-der-Standard-bei-Linux]

• Root in der Konsole

• Root mit GUI

• und der Rest...

Hallo,

klingt gut.

Gruß, noisefloor

kaputtnik schrieb:

appamor stand, und steht derzeit auch gar nicht im Artikel !?!

Stand wohl - ich denke mir das doch nicht aus!

Diese Methode [su; Anm. u.u.] hat sich über einen langen Zeitraum bewährt, sie hat jedoch auch einige Nachteile:

• Vergisst man, sich als root abzumelden, bleibt das System gefährdet

• Man muss sich mindestens zwei (unterschiedliche) Passwörter merken

• Sie verleitet zur ständigen Arbeit als root

• Ohne zusätzliche Lösungen wie AppArmor kann man die Rechte, die ein Root-Benutzer hat, nicht einschränken

Aber zum eigentlichen Thema:

So kommen wir nicht weiter. Ich denke, mittlerweile ist uns allen klar, das sudo in erster Linie dazu da ist, keinen Unsinn mit den Systemdateien zu machen, solange man nicht genau weiß, was man da tut.

Das ich schon anders gewichtet darstellen. Sudo ist ein Programm um in die Haut eines anderen Users zu schlüpfen; meistens ist das die Rolle des Administrators (Ob das su in sudo für switch user, substitute user, oder für superuser steht, ist umstritten).

Alle anderen Sicherheitsbezogenen Dinge sind in dem Artikel überflüssig. Mein Vorschlag wäre daher:

• Kurze(!) Einleitung das "Root werden" in erster Linie .... s.o.

• Kurze Erklärung ROOT → [Baustelle/sudo#Root-der-Standard-bei-Linux]

Root-Account, root-login und su bei anderen Linuxdistributionen - das verwirrt m.E. mehr als es klärt. Hinweg! ☺

• Root in der Konsole

• Root mit GUI

• und der Rest...

Für administrative Aufgaben gibt es einen eigenen Account, den root-Account. Man loggt sich jedoch nicht aus, um sich als root einzuloggen, sondern stellt dem Befehl, für den man diese root-Rechte braucht, ein sudo voran. Man muß dann sein Paßwort eingeben, wodurch verhindert werden kann, daß Programme selbständig solche Befehle ausführen.

Will man ein grafisches Programm starten, dann benutzt man gksudo (gnome/Ubuntu u. Xubuntu) oder kdsudo (kde).

+ warme Worte zu 15 Minuten + Link zu sudoers + vielleicht eine Erklärung zum häufigen Fehler, daß Umleitungen nicht wie vielleicht erwartet klappen:

sudo echo "nameserver 8.8.8.8" > /etc/resolv.conf

weil man die sudo-rechte nicht für das echo braucht, sondern für das Schreiben nach /etc/resolv.conf Dem kann man abhelfen, in dem man das Programm tee benutzt, und dieses mit sudo startet:

echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf 

user unknown schrieb:

kaputtnik schrieb:

• Ohne zusätzliche Lösungen wie AppArmor kann man die Rechte, die ein Root-Benutzer hat, nicht einschränken

Ach da war es versteckt 😉

Das ich schon anders gewichtet darstellen. Sudo ist ein Programm um in die Haut eines anderen Users zu schlüpfen; meistens ist das die Rolle des Administrators

Sehr schön.

(Ob das su in sudo für switch user, substitute user, oder für superuser steht, ist umstritten).

Ist auch nicht sooo wichtig...

Alle anderen Sicherheitsbezogenen Dinge sind in dem Artikel überflüssig. Mein Vorschlag wäre daher:

• Kurze(!) Einleitung das "Root werden" in erster Linie .... s.o.

• Kurze Erklärung ROOT → [Baustelle/sudo#Root-der-Standard-bei-Linux]

Root-Account, root-login und su bei anderen Linuxdistributionen - das verwirrt m.E. mehr als es klärt. Hinweg! ☺

Gut. Der "Benutzer Root" sollte aber trotzdem Erwähnung finden, weil er eine eigenes /home-Verzeichnis hat:

Für administrative Aufgaben gibt es einen eigenen Account, den root-Account. Man loggt sich jedoch nicht aus, um sich als root einzuloggen, sondern stellt dem Befehl, für den man diese root-Rechte braucht, ein sudo voran. Man muß dann sein Paßwort eingeben, wodurch verhindert werden kann, daß Programme selbständig solche Befehle ausführen.

Danach:

• Root in der Konsole

• Root mit GUI

• und der Rest...

Will man ein grafisches Programm starten, dann benutzt man gksudo (gnome/Ubuntu u. Xubuntu) oder kdsudo (kde).

Bitte in extra Überschrift. Das Thema wird immer relevanter und gehört deswegen ins Inhaltsverzeichnis (=Überschrift)

+ warme Worte zu 15 Minuten

Gelten die eigentlich auch für die GUI? Test läuft 😉

+ Link zu sudoers

sudo/Konfiguration

+ vielleicht eine Erklärung zum häufigen Fehler, daß Umleitungen nicht wie vielleicht erwartet klappen:

sudo echo "nameserver 8.8.8.8" > /etc/resolv.conf

weil man die sudo-rechte nicht für das echo braucht, sondern für das Schreiben nach /etc/resolv.conf Dem kann man abhelfen, in dem man das Programm tee benutzt, und dieses mit sudo startet:

echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf 

Gehört IMHO zu "Probleme und Tipps"

Also los!

Hab mal n Anfang gemacht. Der komplette alte Artikel befindet sich unterhalb.

Bitte ergänzen: 15 Minuten, Fehler/Problem bei Terminal Befehlsverknüpfung

Und ansonsten: Anmerkungen, Anmerkungen, Anmerkungen 😉

Ich gebe umunwundenes Feedback:

In der Regel werden damit Operationen ausgeführt, die eigentlich dem Adminstrator des Systems vorbehalten sind.

Nicht eigentlich.
Operationen, die dem Administrator des Systems vorbehalten sind. Punkt.

Eigentlich heißt immer eigentlich nicht. Das ist so ein Kernersches drumrumlabern. Dasein, Sosein, Eigentlichkeit, Holzwege → Heidegger.

Das habe ich gleich geändert.

Bei den großen Desktopumgebungen GNOME oder KDE bemerkt man diese Benutzeränderung nicht wirklich. Man weiß nur, um bestimmte Dinge durchführen zu können muss man sein Passwort eingeben.

Also bitte - wenn man ein Passwort und sudo eingeben muß - das merkt man doch wohl, oder was ist gemeint? Ersatzlos streichen den Absatz. (Habe ich nicht gemacht - vielleicht versteh ich's ja falsch.)

Root - der Standard bei Linux¶

Unter Ubuntu Linux wird standardmäßig außer dem Benutzerkonto automatisch auch ein Konto für Root angelegt. Root ist der Benutzer, der administrative Rechte hat und deshalb vollen Zugriff auf sämtliche Systemrelevanten Dateien und Eigenschaften besitzt.

Sehr große Schrift, und Ubuntu hält sich nicht an den Standard? Hm, hm, hm. Bedenken! Root - der Linuxadministrator schlage ich als Überschrift vor.

Root HOME¶

Jeder Benutzer bekommt ein eigenes Homeverzeichnis im Pfad /home/BENUTZERNAME. Für Root gilt diese Vorgabe nicht! Das HOME-Verzeichnis von Root ist immer /root!

Viel Fett, viele Ausrufezeichen - das scheint ja sehr wichtig zu sein.

cat /etc/passwd | wc -l

bringt auf meinem System 41 User zum Vorschein - einer davon hat ein home-Verzeichnis.

Mein Vorschlag:

Jeder reale Benutzer bekommt ein eigenes Homeverzeichnis im Verzeichnis /home mit seinem Namen. Für Root gilt dies nicht, dessen home-Verzeichnis ist /root.

Statt:

Sudo - Der Standard unter Ubuntu

schlage ich vor

Sudo - Die Administrationstechnik unter Ubuntu

Ich beteilige mich gerne auch an der weiteren Diskussion, aber die nächsten Stunden nicht - vielleicht ist es auch gut nicht alles auf einmal zu diskutieren.

user unknown schrieb:

Ich gebe umunwundenes Feedback:

Is ja auch so gedacht ☺

Nicht eigentlich.
Das habe ich gleich geändert.

+1

Bei den großen Desktopumgebungen GNOME oder KDE bemerkt man diese Benutzeränderung nicht wirklich. Man weiß nur, um bestimmte Dinge durchführen zu können muss man sein Passwort eingeben.

Also bitte - wenn man ein Passwort und sudo eingeben muß - das merkt man doch wohl, oder was ist gemeint? Ersatzlos streichen den Absatz. (Habe ich nicht gemacht - vielleicht versteh ich's ja falsch.)

Gemeint ist, das man in der GUi nicht merkt, das man "eigentlich" den Benutzer wechselt. Man bekommt nur mit: "Aha, jetzt muss ich mein Passwort eingeben..." OK, merkt man im Teminal auch nicht unbedingt. Wollt halt nur deutlich machen, was da eigentlich im Hintergrund passiert.

Root - der Standard bei Linux¶

Unter Ubuntu Linux wird standardmäßig außer dem Benutzerkonto automatisch auch ein Konto für Root angelegt. Root ist der Benutzer, der administrative Rechte hat und deshalb vollen Zugriff auf sämtliche Systemrelevanten Dateien und Eigenschaften besitzt.

Sehr große Schrift, und Ubuntu hält sich nicht an den Standard? Hm, hm, hm. Bedenken!

❓

Root - der Linuxadministrator schlage ich als Überschrift vor.

Generell sind Überschriftenänderungen etwas problematisch. Das liegt daran, das Überschriften gleichzeitig Links sind, auf die von anderen Artikeln verwiesen werden kann (siehe Backlinks zu diesem Artikel). Auf diesen Artikel verweisen gefühlsmässig 100 andere Artikel. Es ist nicht klar, ob auf den Artikel insgesamt, oder nur auf eine Überschrift. Um das zu kontrollieren, müsste man alle 100(?) Artikel durchsehen und gucken, auf was verlinkt wird und die Links entsprechend anpassen.

Alternativ könnte man einen zusätzlichen manuellen Anker setzen (siehe Wiki/Syntax (Abschnitt „Anker“)) der den gleichen Namen erhält wie die ursprüngliche Überschrift. Ich mag keine manuellen Anker. Das gibt immer so hässliche Ankersymbole auf der rechten Seite....

Mein Vorschlag:

Jeder reale Benutzer bekommt ein eigenes Homeverzeichnis im Verzeichnis /home mit seinem Namen. Für Root gilt dies nicht, dessen home-Verzeichnis ist /root.

+1

Statt:

Sudo - Der Standard unter Ubuntu

schlage ich vor

Sudo - Die Administrationstechnik unter Ubuntu

Überschrift... wobei ich auch immer etwas Probleme mit dem Begriff Administration habe. Mag passen, aber iwie mag ich das Wort nicht, auch wenn ich es selber verwandt habe....

Ich beteilige mich gerne auch an der weiteren Diskussion, aber die nächsten Stunden nicht - vielleicht ist es auch gut nicht alles auf einmal zu diskutieren.

+1

Eins nach dem anderen ☺

Hab jetzt mal user_unknowns Vorschläge eingebaut und etwas weiter gemacht. Vllt kriegen wir das ganze in den nächsten Tagen über die Bühne?

Den folgenden Bereich könnte man noch klarer formulieren:

Programm unter anderem, unprivilegiertem Benutzerkontext starten¶

Die Programme gksudo und kdesudo wurden so ausgelegt, dass mit ihnen graphische Programme im Rootkontext ausgeführt werden können. Leider funktioniert dies nicht, wenn Anwendungen im Kontext anderer, unpriviligierter Nutzer ausgeführt werden sollen.

Ich finde das "Leider" an dieser Stelle logisch falsch. Besser wäre es so:

Die Programme gksudo und kdesudo wurden so ausgelegt, dass mit ihnen graphische Programme im Rootkontext ausgeführt werden können. Demzufolge können mittels der beiden Kommandos Programme nicht im Kontext eines anderen unprivilegierten Nutzers ausgeführt werden.

Wer ein graphisches Programm im Kontext eines anderen Benutzers (nicht root) ausführen möchte, der hat dazu folgende Möglichkeiten:

# Bei Befehlen in der Konsole:
su <UserName> -c <Befehl>
# Unter GNOME bzw. Xfce
gksu -w -u <Username> <Befehl>
# Unter KDE
kdesu.distrib -u <Username> <Befehl>  

Anders als die Namen der Programme suggerieren mögen, nutzen die Programme gksu und kdesudo nicht standardmäßig su, sondern sudo. Bei gksudo lässt sich dies durch den Parameter -w ändern. Bei KDE muss das Programm kdesu.distrib verwendet werden. Desweiteren ist zu beachten, dass bei kdesu[.distrib] für Root immer sudo verwendet wird. Ein echtes graphisches su gibt es fur Root unter KDE im Gegensatz zu "gksudo -w" nicht.

Diese Info ist nur sinnvoll, wenn man weiß, was su ist. Außerdem switchen Beispiel und Experteninfor munter zwischen gksu und gksudo hin und her. Im übrigen bleibt die Frage offen, ob denn dann mittels sudo im Terminal die Rolle eines unprivilegierten Nutzers einnehmen kann. In der Einleitung des Artikels hört es sich so an, aber so richtig klar geht es aus dem Artkel nicht hervor. Im Beispiel wird dafür su verwendet.

In den Absatz muss noch kräftig mehr Ordnung rein und es muss klar differenziert werden zwischen su, sudo, gksu, gksudo usw.. Hier kommt man als Leser mächtig ins Schleudern.

Gruß, Martin

Servus ☺ ,

soweit war ich noch gar nicht 😉 Aber ich denke die vorhergehenden Abschnitte sind aus Deiner Sicht dann wohl in Ordnung. Ich hoffe, das user_unknown sich auch nochmal meldet.

Was mich an dem erwähnten Absatz schon stört, ist die Überschrift. Was ist damit gemeint? Warum "unpreveligiert? Warum nicht einfach:

Ein Programm im Kontext eines anderen Benutzers ausführen¶

Es ist möglich, ein Programm so zu starten, als sei es von einem anderen Benutzer gestartet worden. Somit "sieht" man das Programm mit all den Einstellungen, die der andere Benutzer vorgenommen hat. Dies kann hilfreich sein, wenn man z.B. die Benutzerkonfiguration eines Programmes überprüfen möchte. Voraussetzung ist, das man selber der Gruppe admin angehört, also Root-Rechte erlangen kann.

Gibt es noch andere Gründe?

Newubunti schrieb:

Die Programme gksudo und kdesudo wurden so ausgelegt, dass mit ihnen graphische Programme im Rootkontext ausgeführt werden können. Demzufolge können mittels der beiden Kommandos Programme nicht im Kontext eines anderen unprivilegierten Nutzers ausgeführt werden.

Die Aussage stimmte eh nicht. Habs gerade ausprobiert:

$ kdesudo -u test dolphin        
kdeinit4: preparing to launch /usr/lib/libkdeinit4_klauncher.so
[...] 

"test" ist das andere Benutzerkonto. Nach abschicken des Befehls wird mir ein Fenster gezeigt, wo ich das Passwort von "test" eingeben soll. Das ist aber nicht richtig, ich musste mein Passwort eingeben. Danach startet dolphin und man landet im /home--Verzeichnis von "test". Wie man sieht, ist auch kdesudo.distrib nicht notwendig. Habs auch mit meinem Musicplayer probiert, gleiches Ergebnis: Der Player wird mit den Einstellungenbgezeigt, die ich als "test" vorher eingestellt hatte.

In den Absatz muss noch kräftig mehr Ordnung rein und es muss klar differenziert werden zwischen su, sudo, gksu, gksudo usw.. Hier kommt man als Leser mächtig ins Schleudern.

Jo, ich werde das testen und meine Erfahrungen einfließen lassen 😉

Danke für Deinen Kommentar. Immer wieder hilfreich!

Ich möchte folgenden Absatz kommentarlos streichen...

1. kdesu.distrib gibts net mehr

2. kdesudo funktioniert (siehe post vorher)

3. Ich habe lange gesucht, konnte aber keine Unterschiede zwischen kdesudo -u <Benutzer> konsole und gksu -w -u <Benutzer> gnome-terminal herausfinden. Folgendes Szenario wurde getestet:

• Anlegen eines neuen Benutzers test

• Abmelden und als "test" wieder anmelden

• Abmelden und als "kaputtnik" wieder anmelden

• Konsole geöffnet und

kdesudo -u test konsole   #Bei Passwort muss entgegen dem Dialog das eigene Passwort angegeben werden, nicht das von "test" 

bzw. (in einer VM unter GNOME, karmic )

gksu -w -u test gnome-terminal       #Bei Passwort muss das von "test" angegeben werden. 

eingegeben. In den neuen "test"-Konsolen:

test@meiner:~$ whoami
test
test@meiner:~$ echo $HOME
/home/test
test@meiner:~$ ls
Bilder   Dokumente  Musik       Videos
Desktop  Downloads  Öffentlich  Vorlagen
test@meiner:~$ echo test > test.txt
test@meiner:~$ cd /home/kaputtnik
test@meiner:/home/kaputtnik$ echo test > test.txt
bash: test.txt: Permission denied
test@meiner:/home/kaputtnik$ 

Zum Vergleich habe ich einen Screenshot vom gnome-terminal gemacht.

Ausser bei der falschen Passworteingabe bei kdesudo und dem Umstand, dass man im gnome-terminal im "falschen" Homeverzeichnis landet, gibt es keinerlei Unterschiede.

Warum also diese schwer verdauliche Experteninfo?

Hallo,

Denke ich habe den unterschied "su" vs. "sudo" kapiert.

Der Artikel wäre aus meiner Sicht jetzt soweit fertig. Gibt es noch Anmerkungen?