Während der Entwicklung des Frameworks haben einige Nutzer auf Probleme hingewiesen. Einige davon werden hier aufgeführt:
Es scheint, dass etwa jedem fünfzigsten Nutzer dieses Problem widerfährt. Und in der Tat - auch wir kennen es aus der Entwicklung. Genauere Untersuchungen dieses „Bugs“ machten uns glauben, dass es sich entweder um einen Fehler in oder eine fehlerhafte Interpretation der Dokumentation handelt. Warum auch immer dieser Fehler auftritt - er kann mit folgender Prozedur behoben werden:
Öffnen Sie die Datei /etc/fstab
und
setzen Sie die Rootpartition auf ro
wie
„read-only“.
Starten Sie in den Einzelnutzermodus.
Rufen Sie tunefs
-l enable
für /
auf.
Starten Sie in den Mehrbenutzermodus.
Führen Sie mount
-urw
/
aus und ändern
Sie anschließend in der Datei /etc/fstab
die Option ro
zurück in rw
.
Starten Sie das System noch einmal neu.
Achten Sie besonders auf die Ausgabe von
mount
um sich zu versichern, dass die
multilabel
korrekt für das root-Dateisystem
gesetzt wurde.
Dies kann durch die Richtlinie partition
oder einer fehlerhaften Verwendung einer Richtlinie, die mit Labels
arbeitet, auftreten. Zum debuggen versuchen Sie folgendes:
Schauen Sie sich die Fehlermeldungen genau an. Wenn der Nutzer
einer insecure
Klasse angehört, ist
wahrscheinlich die Richtlinie partition
die
Ursache. Versuchen Sie, die Nutzerklasse auf
default
zu stellen und danach die Datenbank mit
cap_mkdb
zu erneuern. Wenn das Problem dadurch
nicht gelöst wird, gehen Sie weiter zu Schritt 2.
Gehen Sie die Label-Richtlinien Schritt für Schritt
nocheinmal durch. Achten Sie darauf, dass für den Nutzer, bei
dem das Problem auftritt, für X11 und das Verzeichnis
/dev
alle Einstellungen
korrekt sind.
Falls all dies nicht helfen sollte, senden Sie die Fehlermeldung und eine Beschreibung ihrer Arbeitsumgebung an die (englisch-sprachige) TrustedBSD Diskussionsliste auf der TrustedBSD Webseite oder an die FreeBSD general questions Mailingliste.
.login_conf
Wenn ich versuche, von root
zu einem anderen
Nutzer des Systems zu wechseln, erhalte ich die Fehlermeldung
_secure_path: unable to state .login_conf.
Diese Meldung wird gewöhnlich ausgegeben, wenn der Nutzer ein
höhere Label-Einstellung hat als der, dessen Identität man
annehmen möchte. Ausführlich: Wenn ein Nutzer
joe
als biba/low
gelabelt wurde,
kann root
, der biba/high
als
Voreinstellung trägt, das Heimatverzeichnis von
joe
nicht einsehen. Das passiert unabhänig
davon, ob root
vorher mit su
die Identität von joe
angenommen hat oder
nicht, da das Label sich nicht ändert. Hier haben wir also einen
Fall, in dem das Gewährleistungsmodell von Biba verhindert, das
der Superuser Objekte einer niedrigeren Integrität betrachten
kann.
Im normalen oder sogar im Einzelbenutzermodus wird
root
nicht anerkannt. Das Kommando
whoami
liefert 0 (null) und su
liefert who are you? zurück. Was geht da
vor?
Das kann passieren, wenn eine Label-Richtlinie ausgeschaltet wird -
entweder durch sysctl(8) oder wenn das Richtlinienmodul entladen
wurde. Wenn eine Richtlinie deaktiviert oder auch nur
vorübergehen deaktiviert wird, muß die
Befähigungsdatenbank neu konfiguriert werden, d.h. die
label
Option muß entfernt werden.
Überprüfen Sie, ob alle label
Einträge
aus der Datei /etc/login.conf
entfernt wurden und
bauen Sie die Datenbank mit cap_mkdb
neu.
Dieser Fehler kann auch auftreten, wenn eine Richtlinie den Zugriff
auf die Datei master.passwd
einschränkt.
Normalerweise passiert das nur, wenn ein Administrator ein Label an
diese Datei vergibt, das mit der allgemeingültigen Richtlinie, die
das System verwendet, in Konflikt steht. In solchen Fällen werden
die Nutzerinformationen vom System ausgelesen und jeder weitere Zugriff
wird blockiert, sobald das neue Label greift. Wenn man die Richtlinie
via sysctl(8) ausschaltet, sollte es erstmal wieder gehen.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.