Wie kann ich /proc/fs/cifs/SecurityFlags dauerhaft festlegen?

Wie kann ich /proc/fs/cifs/SecurityFlags dauerhaft festlegen?

Ich habe es bearbeitet /proc/fs/cifs/SecurityFlags, damit meine CIFS-Mounts korrekt gemountet werden. (Ich musste den Wert 0x81 verwenden.)

Zum Bearbeiten SecurityFlagsgebe ich ein modprobe cifs, wodurch ich das /proc/fs/cifsVerzeichnis sehen kann (ich kann es nicht sehen, bevor ich diesen Befehl eingebe).

Nach dem Neustart SecurityFlagswurde 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.localund berichtete über die Lösung indieser KommentarUnddieser nachfolgende Kommentar.

Die Lösungerscheintsoll wie folgt gewesen sein:

  1. /etc/rc.d/rc.localIn einem Texteditor öffnen .

    [Beachten Sie, dass diese Datei nicht immervorhanden oder standardmäßig verwendetauf neueren Versionen von Ubuntu.]

  2. Fügen Sie diese beiden Zeilen zur Datei hinzu, sodass bei jedem Start von Ubuntu das cifsModul geladen wird (falls dies nicht bereits geschehen ist) und der Text 0x81in „SecurityFlags“ geschrieben wird:

    modprobe cifs
    echo 0x81 > /proc/fs/cifs/SecurityFlags
    
  3. 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/SecurityFlagsund nicht nur dieser SecurityFlagsverwendet wurde (oder dass cddavor 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

verwandte Informationen