summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJan Klemkow <j.klemkow@wemelug.de>2013-01-08 11:04:07 +0100
committerJan Klemkow <j.klemkow@wemelug.de>2013-01-08 11:04:07 +0100
commit9775e1363ebc688147102db3c90beae77bb3a98d (patch)
tree571b2d860749bdce2bd3b279fc51d308cf72c10f
parent3965f9292da17ad9de0fe43a85996c1c56a7af3b (diff)
downloadsksys-9775e1363ebc688147102db3c90beae77bb3a98d.tar.gz
sksys-9775e1363ebc688147102db3c90beae77bb3a98d.tar.bz2
sksys-9775e1363ebc688147102db3c90beae77bb3a98d.zip
Change style.
-rw-r--r--document.asciidoc25
1 files changed, 13 insertions, 12 deletions
diff --git a/document.asciidoc b/document.asciidoc
index e8580f0..b90ac70 100644
--- a/document.asciidoc
+++ b/document.asciidoc
@@ -143,7 +143,7 @@ unterschiedlichen Berechtigungen aufgeteilt.
Das Ziel dabei ist es, den Programmcode mit so wenig Rechten wie moeglich
ausführen zu lassen.
-Als Beispiel sei der Window-Compositer Weston genannt, der im Rahmen des
+Als Beispiel sei der Window-Compositer ``Weston'' genannt, der im Rahmen des
Wayland-Projektes implementiert wird.
Das Programm besteht aus dem Programm ``weston-launch'' und dem eigentlichen
Hauptprogramm ``weston''.
@@ -168,26 +168,27 @@ Das Startprogramm ``weston-launch'' ist ein mit Root-Rechten gestartetes
Vorprogramm für das Hauptprogramm ``weston''.
Es erstellt einen Unix-Domain-Sockets, der den Kommunikationskanal bildet.
Dieser ist die Grundlage für den erwähnten Mechanismus.
-Es startet anschließend weston mit eingeschränkten Rechten (Nutzer-Rechte)
+Es startet anschließend ``weston'' mit eingeschränkten Rechten (Nutzer-Rechte)
und übergibt beim Start den Deskriptor für den Kommunikationskanal.
-Wenn nun zur Laufzeit weston ein Eingabe-Hotplug-Ereignis erhält
-und das Gerät öffnen möchte, so nutzt weston nicht -- wie andere Programme --
-+open(2)+, denn um das Gerät direkt zu Öffnen fehlen die Rechte.
+Wenn nun zur Laufzeit ``weston'' ein Eingabe-Hotplug-Ereignis erhält
+und das Gerät öffnen möchte, so nutzt ``weston'' nicht -- wie andere
+Programme -- +open(2)+, denn um das Gerät direkt zu Öffnen fehlen die Rechte.
Stattdessen wird eine Nachricht über den Kommunikationskanal gesendet,
die mit einem OpCode beschreibt, dass ein Gerät geöffnet werden soll,
und als Parameter den Pfad zum Gerät, z.b. +/dev/input/event0+ enthält.
-Weston-launch empfängt diese Anfrage und prüft, ob es ein zur Öffnung erlaubter
-Pfad ist (z.B. beginnend mit +/dev/input/+).
+``Weston-launch'' empfängt diese Anfrage und prüft, ob es ein zur Öffnung
+erlaubter Pfad ist (z.B. beginnend mit +/dev/input/+).
Falls erlaubt, wird das Gerät geöffnet und der Deskriptor über den
Kommunikationskanal als Socket-Control-Message an ``weston'' als Antwort
-übertragen. Weston erhält damit einen Deskriptor, der sich nicht
-von einem durch direkten Aufruf von +open(2)+ geöffneten unterscheidet.
+übertragen.
+``Weston'' erhält damit einen Deskriptor, der sich nicht von einem durch
+direkten Aufruf von +open(2)+ geöffneten unterscheidet.
// TODO: Ähnliches Szenario: DRM Set Master
-Weston läuft somit im User-Mode und kann bestimmte Operationen,
-über weston-launch ausführen lassen.
-Wenn eine Sicherheitslücke in Weston nun zur Ausführung von schädlichem
+``Weston'' läuft somit im User-Mode und kann bestimmte Operationen,
+über ``weston-launch'' ausführen lassen.
+Wenn eine Sicherheitslücke in ``Weston'' nun zur Ausführung von schädlichem
Programm-Code führen sollte, könnten nur die Root-Operationen ausgeführt
werden, die ``weston-launch'' erlaubt -- nicht aber alle für Root erlaubten.