
Ich habe es bearbeitet /proc/fs/cifs/SecurityFlags
, damit meine CIFS-Mounts korrekt gemountet werden. (Ich musste den Wert 0x81 verwenden.)
Zum Bearbeiten SecurityFlags
gebe ich ein modprobe cifs
, wodurch ich das /proc/fs/cifs
Verzeichnis sehen kann (ich kann es nicht sehen, bevor ich diesen Befehl eingebe).
Nach dem Neustart SecurityFlags
wurde der Wert auf den Standardwert 0x7 zurückgesetzt.
Wie kann dies dauerhaft eingestellt werden, sodass der Wert 0x81 nach dem Neustart erhalten bleibt?
Antwort1
Es wird als Option festgelegt, wenn der Kernel kompiliert wird
/proc ist ein virtuelles Dateisystem, siehehttp://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html
/proc ist insofern etwas ganz Besonderes, als es auch ein virtuelles Dateisystem ist. Es wird manchmal als Pseudodateisystem für Prozessinformationen bezeichnet. Es enthält keine „echten“ Dateien, sondern Laufzeitsysteminformationen (z. B. Systemspeicher, eingebundene Geräte, Hardwarekonfiguration usw.). Aus diesem Grund kann es als Kontroll- und Informationszentrum für den Kernel betrachtet werden. Tatsächlich sind viele Systemdienstprogramme einfach Aufrufe von Dateien in diesem Verzeichnis. Beispielsweise ist „lsmod“ dasselbe wie „cat /proc/modules“, während „lspci“ ein Synonym für „cat /proc/pci“ ist. Indem Sie Dateien in diesem Verzeichnis ändern, können Sie sogar Kernelparameter (sysctl) lesen/ändern, während das System läuft.
Sehenhttps://www.kernel.org/doc/readme/Documentation-filesystems-cifs-README
SecurityFlags Flags, die die Sicherheitsverhandlung und auch die Paketsignierung steuern. Authentifizierungsflags (darf/muss) (z. B. für NTLM und/oder NTLMv2) können mit den Signaturflags kombiniert werden. Die Angabe von zwei verschiedenen Passwort-Hashing-Mechanismen (als „muss verwendet werden“) macht dagegen wenig Sinn. Standardflags sind 0x07007 (NTLM, NTLMv2 und Paketsignierung zulässig). Die maximal zulässigen Flags, wenn Sie Mounts auf Servern mit schwächeren Passwort-Hashes zulassen möchten, sind 0x37037 (lanman, plaintext, ntlm, ntlmv2, Signatur zulässig). Einige SecurityFlags erfordern die Aktivierung der entsprechenden Menuconfig-Optionen (lanman und plaintext erfordern beispielsweise CONFIG_CIFS_WEAK_PW_HASH). Die Aktivierung der Plaintext-Authentifizierung erfordert derzeit auch die Aktivierung der Lanman-Authentifizierung in den Sicherheitsflags, da das CIFS-Modul nur das Senden von Laintext-Passwörtern mit der älteren Lanman-Dialektform des Sitzungs-Setups SMB unterstützt. (z. B. für die Authentifizierung mit Klartext-Passwörtern setzen Sie die SecurityFlags auf 0x30030):
may use packet signing 0x00001
must use packet signing 0x01001
may use NTLM (most common password hash) 0x00002
must use NTLM 0x02002
may use NTLMv2 0x00004
must use NTLMv2 0x04004
may use Kerberos security 0x00008
must use Kerberos 0x08008
may use lanman (weak) password hash 0x00010
must use lanman password hash 0x10010
may use plaintext passwords 0x00020
must use plaintext passwords 0x20020
(reserved for future packet encryption) 0x00040
Sie können dies mit Mount-Optionen überschreiben
Sehenhttps://www.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html
sec= Sicherheitsmodus. Zulässige Werte sind:
kein Verbindungsversuch als Null-Benutzer (kein Name)
krb5 Kerberos Version 5-Authentifizierung verwenden
krb5i Kerberos-Authentifizierung und Paketsignierung verwenden
ntlm NTLM-Passwort-Hashing verwenden (Standard)
ntlmi NTLM-Passwort-Hashing mit Signierung verwenden (wenn /proc/fs/cifs/PacketSigningEnabled aktiviert ist oder wenn der Server eine Signierung erfordert, kann dies auch die Standardeinstellung sein)
ntlmv2 NTLMv2-Passwort-Hashing verwenden
ntlmv2i Verwenden Sie NTLMv2-Passwort-Hashing mit Paketsignierung
[NB: Dieser [sec-Parameter] befindet sich in der Entwicklung und wird voraussichtlich im CIFS-Kernelmodul 1.40 und höher verfügbar sein.]
Wenn Sie Hilfe benötigen, posten Sie Ihre Mount-Optionen oder Ihren Eintrag in der fstab und die Fehlermeldung, die Sie beim Mount-Versuch erhalten.
Antwort2
Das Originalplakat,Paul Rosas, konnte das Problem durch Hinzufügen eines Befehls zu lösen rc.local
und berichtete über die Lösung indieser KommentarUnddieser nachfolgende Kommentar.
Die Lösungerscheintsoll wie folgt gewesen sein:
/etc/rc.d/rc.local
In einem Texteditor öffnen .[Beachten Sie, dass diese Datei nicht immervorhanden oder standardmäßig verwendetauf neueren Versionen von Ubuntu.]
Fügen Sie diese beiden Zeilen zur Datei hinzu, sodass bei jedem Start von Ubuntu das
cifs
Modul geladen wird (falls dies nicht bereits geschehen ist) und der Text0x81
in „SecurityFlags“ geschrieben wird:modprobe cifs echo 0x81 > /proc/fs/cifs/SecurityFlags
Speichern Sie die Datei und beenden Sie den Texteditor.
Ich sage, dass es so „erscheint“, weil Informationen über Leerzeichen, einschließlich der neuen Zeile zwischen, wie ich glaube, zwei separaten Befehlen, nicht sichtbar sind.im Kommentar, und weil ich glaube, dass der vollständige Pfad /proc/fs/cifs/SecurityFlags
und nicht nur dieser SecurityFlags
verwendet wurde (oder dass cd
davor ein Befehl hinzugefügt wurde), da die Lösung sonst nicht funktioniert hätte.
Antwort3
Für eine dauerhaftere Lösung schlage ich vor, eineudevRegel zum Festlegen des Werts von SecurityFlags. Dadurch wird der Wert jedes Mal festgelegt, wenn das CIFS-Modul geladen wird. Sie definieren Ihre Regeln in /etc/udev/rules.d.
50-cifs-securityflags.regeln:
# Set SecurityFlags to 0x81.
ACTION=="add", SUBSYSTEM=="module", KERNEL=="cifs", RUN+="/bin/sh -c 'echo 0x81 > /proc/fs/cifs/SecurityFlags'"
und dann udev neu laden mitudevadm control --reload-rules && udevadm trigger