Das Konzept der Dateirechte unter Linux bereitet Benutzern wie Administratoren gerade in der Anfangszeit immer wieder Probleme. Grund genug also, hier einen genaueren Blick darauf zu werfen! Die Notwendigkeit von Dateirechten im PC-Bereich fiel mit der zunehmenden Nutzung einzelner Geräte durch mehrere Personen zusammen. Microsoft beispielsweise führte Dateirechte mit dem Start des Dateisystems NTFS Anfang der 1990er Jahre ein. Bereits bei Unix-Dateisystemen gab es die gleichen Berechtigungsstrukturen, wie sie heute unter Linux bei den gängigen Dateisystemen (ext2, ext3, ext4, btrfs, xfs, reiserfs usw.

Erweiterte Dateirechte (ACL) Der erste Artikel der Reihe ‘Dateirechte’ behandelte Besitz- und Zugriffsrechte. Die Fortsetzung ging auf das Setzen und Verändern der Dateirechte ein. Im diesem letzten Teil behandeln wir erweiterte Dateirechte, die Sie über ‘Access Control Lists’ (ACL) steuern. Historisch gab es in unixoiden Betriebssystemen lediglich die Möglichkeit, Dateirechte über einen Benutzer, eine Gruppe oder alle sonstigen zu definieren. Die Details dazu haben wir bereits kennengelernt. Grundsätzlich hat sich an diesem Ansatz nichts geändert; in heutigen Multiuser-Umgebungen stößt der Ansatz allerdings oft an seine Grenzen und wurde daher mit den ‘erweiterten Dateirechten’ ``aufgebohrt''.

Dateirechte setzen und verändern Nachdem der letzte Artikel dieser Reihe die Besitz- und Zugriffsrechte ausführlich erklärt hat, geht es hier um die wichtigen Kommandos, mit denen Sie die Dateirechte ‘ändern’: chown, chgrp und chmod. Zuvor aber stellen wir das Kommando stat vor, das die Rechte sehr übersichtlich anzeigt: user@linux ~$ stat kapitel.txt File: 'kapitel.txt' Size: 819 Blocks: 8 IO Block: 4096 regular file Device: fd06h/64774d Inode: 439267 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 4000/mgisbers) Gid: ( 4000/mgisbers) Access: 2013-03-25 18:52:04.

Geschichtsstunde: ifconfig Vielen ist der Befehl ifconfig ein Begriff, ist er doch seit Jahrzehnten für die Konfiguration des Netzwerks unter Unix- oder Linux-Systemen zuständig. So sehen beispielsweise Aufrufe zum Setzen einer IP-Adresse und Anzeigen der Konfiguration aus: root@linux:~# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up root@linux:~# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::225:90ff:fec0:ffee prefixlen 64 scopeid 0x20<link> ether 00:25:90:c0:ff:ee txqueuelen 1000 (Ethernet) RX packets 123346 bytes 120154576 (114.

Programme, die innerhalb einer Shell - z. B. /bin/bash - gestartet werden warten, normalerweise, auf das Ende ihrer Ausführung und belegen in der Zeit die Konsole. Einfach lässt sich dies durch das Kommando sleep darstellen: tux@linux ~ $ sleep 10 Erst 10 Sekunden nach dem Start des Kommandos erscheint ein neuer Prompt und es werden neue Kommandos ausgeführt. Zwar kann man während das Kommando sleep die Konsole belegt schon neue Kommandos eingeben, aber die eigentliche Ausführung startet erst nach Ende des vorherigen Kommandos.

Während ein Rechner per SSH zu einem anderen Rechner verbunden ist, kommt es teilweise vor, dass die Verbindung kurzzeitig unterbrochen werden müsste um auf die lokale Shell zugreifen zu können. Diese Unterbrechungen sind im Umfeld der Shell recht üblich und werden dort über die Tastenkombination STRG+z durchgeführt. Damit wird der aktuelle Prozess im Job-Management angehalten und die Shell zur Eingabe von Befehlen freigegeben. Nach der Arbeit mit dem Befehl erfolgt eine Wiederaufnahme des Befehls über fg.

Bereits in dem letzten Artikel dieser Reihe haben wir die Datei authorized_keys kennengelernt und erfahren, wie man mit ihr einen Login ohne Kennworteingabe durchführt. SSH-Agent Solange wir, wie es empfohlen ist, auf den ‘privaten Schlüssel’ ein Kennwort legen, muss weiterhin bei jedem Login ein Kennwort eingegeben werden. Dies ist allerdings nicht das Kennwort des Benutzers auf der angesprochenen Maschine, sondern das Kennwort des lokal abgelegten ‘privaten Schlüssels’. Die Entwickler des SSH-Protokolls haben für diesen Zweck einen Mechanismus eingebaut, über den ein Agent die Verwaltung der Schlüssel übernimmt und bei Zugriff auf einen Server dem ssh-Kommando nutzbare Schlüssel anbietet.

Nachdem sich der erste Teil der Reihe mit den grundlegenden Funktionen der ‘Secure SHell’ befasst hat, gehen wir nun einen Schritt weiter. Thema dieses Artikels ist die Anmeldung ohne Passwort per ‘Public Key Authentifizierung’. Öffentlicher und privater Schlüssel Die Idee eines Schlüssels ist hinreichend bekannt: Er gewährt Zugang zu einem System. Ein symmetrischer Schlüssel – also ein Schlüssel lediglich zum Verschlüsseln und Entschlüsseln – genügt unseren Ansprüchen an dieser Stelle allerdings nicht.