LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

Message
Author
loik
Posts: 2299
Joined: Wed Dec 12, 2018 2:01 pm

LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#1 Post by loik »

Hallo, Forum.

Ich habe MX-21.1-32bit-xfce in VirtualBox installiert.

Code: Select all

$ inxi -Fxxxrza
Use of uninitialized value within @split in pattern match (m//) at /usr/local/bin/inxi line 25001.
System:    Kernel: 5.10.0-16-686-pae i686 bits: 32 compiler: gcc v: 10.2.1 
           parameters: BOOT_IMAGE=/vmlinuz-5.10.0-16-686-pae 
           root=UUID=1fd00801-1628-4dd0-8ff2-317c6f791a8d ro quiet splash 
           Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.16.1 vt: 7 
           dm: LightDM 1.26.0 Distro: MX-21.1_386 Wildflower April 9  2022 
           base: Debian GNU/Linux 11 (bullseye) 
Machine:   Type: Virtualbox System: innotek product: VirtualBox v: 1.2 serial: <filter> 
           Chassis: Oracle Corporation type: 1 serial: <filter> 
           Mobo: Oracle model: VirtualBox v: 1.2 serial: <filter> BIOS: innotek v: VirtualBox 
           date: 12/01/2006 
CPU:       Info: Quad Core model: Intel Core i5-3470S bits: 32 type: MCP arch: Ivy Bridge 
           family: 6 model-id: 3A (58) stepping: 9 microcode: 19 cache: L2: 6 MiB 
           flags: avx nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 23146 
           Speed: 2893 MHz min/max: N/A Core speeds (MHz): 1: 2893 2: 2893 3: 2893 4: 2893 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf mitigation: PTE Inversion; VMX: EPT disabled 
           Type: mds mitigation: Clear CPU buffers; SMT Host state unknown 
           Type: meltdown mitigation: PTI 
           Type: mmio_stale_data status: Not affected 
           Type: spec_store_bypass status: Vulnerable 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Retpolines, STIBP: disabled, RSB filling 
           Type: srbds status: Unknown: Dependent on hypervisor status 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.18.0.0 bus-ID: 00:02.0 
           chip-ID: 15ad:0405 class-ID: 0300 
           Display: x11 server: X.Org 1.20.11 compositor: xfwm4 v: 4.16.1 driver: loaded: vmware 
           unloaded: fbdev,modesetting,vesa display-ID: :0.0 screens: 1 
           Screen-1: 0 s-res: 1440x900 s-dpi: 96 s-size: 381x238mm (15.0x9.4") 
           s-diag: 449mm (17.7") 
           Monitor-1: Virtual1 res: 1440x900 hz: 60 
           OpenGL: renderer: SVGA3D; build: RELEASE; LLVM; v: 2.1 Mesa 20.3.5 direct render: Yes 
Audio:     Device-1: Intel 82801AA AC97 Audio vendor: Dell driver: snd_intel8x0 v: kernel 
           bus-ID: 00:05.0 chip-ID: 8086:2415 class-ID: 0401 
           Sound Server-1: ALSA v: k5.10.0-16-686-pae running: yes 
           Sound Server-2: PulseAudio v: 14.2 running: yes 
Network:   Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020 
           bus-ID: 00:03.0 chip-ID: 8086:100e class-ID: 0200 
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus 
           v: N/A modules: i2c_piix4 port: d200 bus-ID: 00:07.0 chip-ID: 8086:7113 
           class-ID: 0680 
Drives:    Local Storage: total: 12.22 GiB used: 32.56 GiB (266.4%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda maj-min: 8:0 vendor: VirtualBox model: VBOX HARDDISK size: 12.22 GiB 
           block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s type: N/A serial: <filter> 
           rev: 1.0 scheme: MBR 
Partition: ID-1: / raw-size: 11.08 GiB size: 10.8 GiB (97.51%) used: 8.57 GiB (79.4%) fs: ext4 
           dev: /dev/dm-0 maj-min: 253:0 mapped: root.fsm 
           ID-2: /boot raw-size: 512 MiB size: 487.2 MiB (95.16%) used: 427.3 MiB (87.7%) 
           fs: ext4 dev: /dev/sda1 maj-min: 8:1 
Swap:      Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 624 MiB used: 0 KiB (0.0%) priority: -2 
           dev: /dev/dm-1 maj-min: 253:1 mapped: swap 
Sensors:   Message: No sensor data found. Is lm-sensors configured? 
Repos:     Packages: note: see --pkg apt: 2065 lib: 1014 flatpak: 0 
           No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian bullseye-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian bullseye main contrib non-free
           2: deb http://security.debian.org/debian-security bullseye-security main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://nl.mxrepo.com/mx/repo/ bullseye main non-free
Info:      Processes: 233 Uptime: 8m wakeups: 130 Memory: 1.71 GiB used: 870.8 MiB (49.8%) 
           Init: SysVinit v: 2.96 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: 10.2.1 
           alt: 10 Shell: Bash v: 5.1.4 running-in: xfce4-terminal inxi: 3.3.06 
Host ist MX21-1-64bit-xfce.

Code: Select all

$ inxi -Fxxxrza
System:    Kernel: 5.10.0-16-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-16-amd64 
           root=UUID=bbb85abb-c0b9-46dd-b282-c939dde331a5 ro quiet splash 
           Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.16.1 vt: 7 
           dm: LightDM 1.26.0 Distro: MX-21.1_x64 Wildflower October 20  2021 
           base: Debian GNU/Linux 11 (bullseye) 
Machine:   Type: Desktop System: Hewlett-Packard product: HP Compaq Elite 8300 USDT v: N/A 
           serial: <filter> Chassis: type: 3 serial: <filter> 
           Mobo: Hewlett-Packard model: 3398 serial: <filter> UEFI: Hewlett-Packard 
           v: K01 v02.05 date: 05/07/2012 
Battery:   Device-1: hidpp_battery_0 model: Logitech Wireless Touch Keyboard K400 
           serial: <filter> charge: 55% (should be ignored) rechargeable: yes 
           status: Discharging 
CPU:       Info: Quad Core model: Intel Core i5-3470S bits: 64 type: MCP arch: Ivy Bridge 
           family: 6 model-id: 3A (58) stepping: 9 microcode: 21 cache: L2: 6 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 23147 
           Speed: 1779 MHz min/max: 1600/2900 MHz Core speeds (MHz): 1: 1779 2: 1806 3: 1856 
           4: 1694 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled 
           Type: mds mitigation: Clear CPU buffers; SMT disabled 
           Type: meltdown mitigation: PTI 
           Type: mmio_stale_data status: Not affected 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 
           mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling 
           Type: srbds status: Vulnerable: No microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics 
           vendor: Hewlett-Packard driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0152 
           class-ID: 0300 
           Display: x11 server: X.Org 1.20.11 compositor: xfwm4 v: 4.16.1 driver: 
           loaded: modesetting unloaded: fbdev,vesa display-ID: :0.0 screens: 1 
           Screen-1: 0 s-res: 3360x1080 s-dpi: 96 s-size: 889x285mm (35.0x11.2") 
           s-diag: 934mm (36.8") 
           Monitor-1: DP-1 res: 1440x900 hz: 60 dpi: 90 size: 408x255mm (16.1x10.0") 
           diag: 481mm (18.9") 
           Monitor-2: HDMI-2 res: 1920x1080 hz: 60 dpi: 92 size: 531x299mm (20.9x11.8") 
           diag: 609mm (24") 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 2500 (IVB GT1) v: 4.2 Mesa 20.3.5 
           compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Hewlett-Packard 
           driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1e20 class-ID: 0403 
           Device-2: Creative SoundBlaster MP3+ type: USB 
           driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-1.2:4 chip-ID: 041e:3010 
           class-ID: 0300 
           Device-3: Logitech Logitech Z205 type: USB driver: hid-generic,snd-usb-audio,usbhid 
           bus-ID: 3-2.2:5 chip-ID: 046d:0a19 class-ID: 0300 
           Sound Server-1: ALSA v: k5.10.0-16-amd64 running: yes 
           Sound Server-2: PulseAudio v: 14.2 running: yes 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Hewlett-Packard driver: e1000e 
           v: kernel port: f060 bus-ID: 00:19.0 chip-ID: 8086:1502 class-ID: 0200 
           IF: eth0 state: down mac: <filter> 
           Device-2: Realtek RTL8191SU 802.11n WLAN Adapter type: USB driver: r8712u 
           bus-ID: 3-3:3 chip-ID: 0bda:8172 class-ID: 0000 serial: <filter> 
           IF: wlan0 state: up mac: <filter> 
Drives:    Local Storage: total: 614.81 GiB used: 187.63 GiB (30.5%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda maj-min: 8:0 vendor: Seagate model: ST9160301AS size: 149.05 GiB 
           block-size: physical: 512 B logical: 512 B speed: 1.5 Gb/s type: HDD rpm: 5400 
           serial: <filter> rev: SDM2 scheme: MBR 
           ID-2: /dev/sdb maj-min: 8:16 type: USB vendor: Realtek model: RTL9210B-CG 
           size: 465.76 GiB block-size: physical: 512 B logical: 512 B type: N/A 
           serial: <filter> rev: 1.00 scheme: GPT 
Partition: ID-1: / raw-size: 34.79 GiB size: 33.94 GiB (97.58%) used: 21.82 GiB (64.3%) fs: ext4 
           dev: /dev/sdb7 maj-min: 8:23 
           ID-2: /boot/efi raw-size: 512 MiB size: 511 MiB (99.80%) used: 3.2 MiB (0.6%) 
           fs: vfat dev: /dev/sdb2 maj-min: 8:18 
Swap:      Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 4.15 GiB used: 0 KiB (0.0%) priority: -2 
           dev: /dev/sdb11 maj-min: 8:27 
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C 
           Fan Speeds (RPM): N/A 
Repos:     Packages: note: see --pkg apt: 3187 lib: 1695 flatpak: 0 
           No active apt repos in: /etc/apt/sources.list 
           No active apt repos in: /etc/apt/sources.list.d/deb-multimedia.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian bullseye-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian bullseye main contrib non-free
           2: deb http://security.debian.org/debian-security bullseye-security main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/librewolf.list 
           1: deb [arch=amd64] http://deb.librewolf.net bullseye main
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://nl.mxrepo.com/mx/repo/ bullseye main non-free
           Active apt repos in: /etc/apt/sources.list.d/opera-stable.list 
           1: deb https://deb.opera.com/opera-stable/ stable non-free
           Active apt repos in: /etc/apt/sources.list.d/signal-xenial-added-by-mxpi.list 
           1: deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main
           Active apt repos in: /etc/apt/sources.list.d/skype-stable.list 
           1: deb [arch=amd64] https://repo.skype.com/deb stable main
           Active apt repos in: /etc/apt/sources.list.d/spotify.list 
           1: deb http://repository.spotify.com stable non-free
           Active apt repos in: /etc/apt/sources.list.d/teamviewer.list 
           1: deb http://linux.teamviewer.com/deb stable main
           Active apt repos in: /etc/apt/sources.list.d/vivaldi.list 
           1: deb [arch=amd64] http://repo.vivaldi.com/stable/deb/ stable main
Info:      Processes: 241 Uptime: 46m wakeups: 7 Memory: 7.65 GiB used: 3.6 GiB (47.1%) 
           Init: SysVinit v: 2.96 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: 10.2.1 
           alt: 10 Shell: Bash v: 5.1.4 running-in: xfce4-terminal inxi: 3.3.06 
Ich habe nun zum ersten mal bei der Installation ausgewählt, dass das System verschlüsselt sein soll.
Root und Home nicht getrennt.
Installationsmedium die ISO, die z.Z. von MX zum Herunterladen angeboten wird.

Hat so weit geklappt.
Wenn ich das System boote, kommt die Passwortabfrage der Verschlüsselung.
Erst nach Eingabe, geht es weiter zum Anmeldebildschirm für den Benutzer.

Mein festgelegtes Passwort wird also angenommen.

Wenn ich dann auf meinem Desktop bin, kann ich auf meine Homedatei ebenso zugreifen, wie auf das Dateisystem.

Es wird aber in Thunar, in der Seitenleiste, auch angezeigt, die Festplatte bzw. Partition.
Hängt ein schloss drann.
Dahinter sollte ja eigentlich wieder das Dateisystem zu finden sein.
Wenn ich also dort draufklicke, kommt eine Passwortabfrage.
Dort gebe ich das Passwort ein.
Dann kommt eine neu Abfrage, die nach dem Root-Passwort fragt.
Das gebe ich ein.
Dann passiert nichts weiter.
Wenn ich wieder auf das verschlüsselte Laufwerk klicke, beginnt die doppelte Abfrage von vorne.

Öffne ich "gnome-disks", wird das Laufwerk ebenfalls als abgeschlossen angezeigt.
will ich es öffnen, erhalte ich wieder die doppelte Passwortabfrage, ohne das ich das gewünschte Ziel erreiche.

Das gleiche geschieht, wenn ich versuche per Live-Medium auf das Laufwerk zuzugreifen.

Warum ist das so ?

mike7

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#2 Post by mike7 »

Hallo loik,

das ist es halt. So kenne ich es, seit Jahren..! Daher war/ist für mich das Schloß (habe es fürs Forum sogar kopiert, ist zwar dark, weil ich alles dark habe, aber doch gut zu sehen - siehe meinen Beitrag ...'Artefakt ... resistent' darunter) eine nur lästige Angelegenheit auf dem Desktop. Deshalb wird es 'Artefakt' genannt, da ich dahinter keinen praktischen Sinn sehe.

Geht bei mir also, wie bei dir, gleichfalls nicht (Luks in Live). Inzwischen ist das Schloß von mir entfernt worden (Einstellungen-Schreibtisch-Objekte). Beim USB-Einstecken habe ich ihn im Tunar, kann ihn hier öffnen. Wenn ich Live-Stick mit Schnappschuss brennen will, reicht es die rechte Maus zu drücken, dann MX-Tools ... usw. Geht auch so.

mfg

mike7

loik
Posts: 2299
Joined: Wed Dec 12, 2018 2:01 pm

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#3 Post by loik »

Hallo, Mike7.
Danke für deine Antwort.

Naja, ein "Schloss-Symbol" ist auf meinem Schreibtisch nicht zu sehen, weil ich in den Schreibtischeinstellungen, bei Symbole, gar keinen Haken bei "entfernbare Datenträger" gesetzt hatte.

Aber mich stört auch gar nicht, dass da ein Schloss angezeigt wird.
Mich stört, dass ich es nicht öffnen kann.
Das mein eigens dafür hinterlegtes Passwort nicht akzeptiert wird.
Das zusätzlich nach root gefragt wird, was dann aber auch nichts ändert.

Das verstehe ich nicht.

loik
Posts: 2299
Joined: Wed Dec 12, 2018 2:01 pm

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#4 Post by loik »

o.k.
was aber geht, ist dass ich irgend einen Ordner als root öffne.
dann wird mir in der Seitenleiste des Thunar-root-Fensters die entsprechende Partition als
"Wurzelordner des Dateisystems" angezeigt.
Beim USER hingegen heißt es "12 GB verschlüsselt"
mit schloss drann.

mike7

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#5 Post by mike7 »

@loik:

wir betrachten das GLEICHE Thema beide aus einem gegenüber liegendem Blickwinkel. Ich sage, da ich es (Luks im Live-Betrieb etc.) nur so, wie du es heute beschreibst, seit Jahren!!! kenne, sehe ich in dem ..."Schloß" einen nutzlosen, unschönen "Artefakt". Den ich in den Einstellungen entferne. = Dadurch habe ich demnächst (XFCE-Desktop) nicht den eventuell eingesteckten USB-Stick auf der Arbeitsfläche. Was viele, die ich kenne, möchten. Mich stört es aber nicht.

Wenn es aber die elegantere Möglichkeit gäbe, dass man einen eingestöpselten USB-Stick doch auf dem Schreibtisch haben könnte, und zwar OHNE den nutzlosen, häßlichen Artefakt, würde ich es so bevorzugen. Das ist alles.

mfg

mike7

loik
Posts: 2299
Joined: Wed Dec 12, 2018 2:01 pm

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#6 Post by loik »

Hallo, Mike7.
Ja, es geht und beiden um die LUKS-verschlüsselung.
Aber der Unterschied liegt nicht in der Betrachtung aus unterschiedlichen Winkeln.

Dir geht es, so lese ich es zu mindest, um Optik, um Darstellung.

Die ist für gar kein Thema.

Mir geht es um die Zugreifbarkeit.

Und wie ich nun herausgefunden habe, ist die wohl gegeben, wenn ich als root agiere.



Zusätzlich habe ich aber noch mal in MX-Tweak unter "Sonstiges" rumgefummelt.
Habe erlaubt, dass der einfache Benutzer interne Laufwerke einhängen darf und habe für administrative Aufgaben statt bisher root nun den Benutzer eingetragen.
Neu gestartet.
Hat nix verändert.

Ich vermute, dass der einfache Benutzer auch noch zur Gruppe "root" hinzugefügt werden muss.

Das wollen WIR aber nicht. ;)

Na gut.
Eine umwegige Lösung habe ich ja nun gefunden.

mike7

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#7 Post by mike7 »

@loik:

klar doch. Als root nicht, wäre umständlich. Als einfacher Benutzer (sudo!!). Das heißt root, es nutzt mir nichts.

Binn gespannt, ob jemand einen Sinn dafür findet. Der nich übergeschnappt wäre.

mfg

mike7

loik
Posts: 2299
Joined: Wed Dec 12, 2018 2:01 pm

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#8 Post by loik »

Ich habe nun noch einmal das MX-Live-ISO bemüht.
Das welches ich bei MX heruntergeladen hatte.

Wenn ich von dem aus ( mit meinen neuen Erfahrungen ) auf das verschlüsselte Laufwerk zugreifen möchte, passiert folgendes:

Versuche ich es so, wie zu vor schon beschrieben, in dem ich einen Ordner des Dateisystems als root öffne ( root/root), dann wird mir im Thunar-Root-Fenster das verschlüsselte Laufwerk gar nicht angezeigt.
Also, als root komme ich dort nicht weiter.

wenn ich es als Benutzer "demo" versuche, werde ich als erstes nach der LUKS-Passfrase gefragt.
Danach kommt sofort das nächste Fenster, welches vermeldet, dass eine Weitere Legitimation notwendig ist.
Gebe ich dort als Passwort "root" ein, so passiert nix.
Das Fenster verschwindet zwar, aber das Laufwerk bleibt gesperrt.

Gebe ich aber dort in das zweite Abfragefenster als Passwort "demo" ein .... ZACK, das Laufwerk ist geöffnet.

Ich habe in den Benutzer einstellungen und den Gruppenzugehörigkeiten gerade noch mal nachgeschaut ( im Live-ISO ),
"demo" ist nicht der Gruppe "root" zugeordnet.

Warum geht das im Installierten System nicht ?
weder wird bei der zweiten PW-Abfrage das user-PW angenommen, noch "demo".
Das Fenster schüttelt sich nur und beharrt darauf, das es das Root-PW sein soll.
Wenn ich das eingebe, verschwindet das Abfrage-Fenster.
Aber das Laufwerk bleibt weiterhin für den normalen Benutzer gesperrt.
Ich hätte erwartet, dass sich im Zuge des Entsperrens ein Thunar-Root-Fenster öffnet.

Das muss ich dann extra noch mal machen per rechtem Mausklick auf irgendeinem Ordner ( nicht auf den Verschlüsselten -> geht nicht ) und dann "Thunar als Root hier öffnen" wählen. Nochmal Root-PW eingeben. Dann endlich ist der Zugriff möglich.

Ich dann auch getestet, wie es sich verhält,
( nach dem ich, nach dem das System frisch hochgefahren ist, ich mich als BENUTZER eingeloggt habe und ich auf meinem Desktop bin )
wenn ich als normaler Nutzer nicht auf das verschlüsselte Laufwerk klicke und nicht die PW-Abfragen initiiere, sondern gleich als Root über irgend einen Ordner ( "Thunar als Root hier öffnen" ) in den Dateipfad gehe.
Ergebnis:
Root hat dann vollen Zugriff auf das Laufwerk.
Es ist nicht gesperrt.


Ich finde das alles ein wenig seltsam.
Widersprüchlich.

Root- und Benutzer-PW sind natürlich nicht die selben.
Aber, weil ich beim Installieren nicht wusste, was ich tat,

sind LUKS- und Benutzer-PW das selbe.

Das erklärt das Freigabeverhalten für mich aber noch weniger.


Nun kann ich ja wiederholt feststellen, dass ich herausgefunden habe, wie ich auf das gesperrte Laufwerk zugreifen kann.
Deshalb hatte ich auch schon auf gelöst geklickt.
Aber ich würde diesen geschilderten Widerspruch gerne verstehen.

Wer kann mir das aufdröseln.
Im Netz bin ich nicht fündig geworden.

Danke.

loik
Posts: 2299
Joined: Wed Dec 12, 2018 2:01 pm

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#9 Post by loik »

Ach gucke mal ...

Zum Thema WIDERSPRÜCHLICH gleich noch ein drauf:

Ich habe ein Live-ISO-Snapshot von MX-19.4-32bit-xfce gebootet.
Habe dort in Thunar des einfachen Benutzers auf das gesperrte Laufwerk geklickt.
Es erschien die LUKS-PW-Abfrage.
Ich habe dort die LUKS-Passphrase eingegeben.
Tattaaaaa ... Das Laufwerk wurde entsperrt, und ich konnte als einfache Nutzer darauf zugreifen, ohne weiteres gehampel.
So sollte es doch wohl grundsätzlich sein, Oder.

Ist es aber wie geschildert nicht.
Warum ?

mike7

Re: LUKS-Passwort funktioniert beim Booten, aber nicht im Laufenden Betrieb

#10 Post by mike7 »

@loik:

Respekt. Du gehst mit dem Thema richtig um.

Was mich betrifft, hab mir diese Fragen vor Jahren auch gestellt. Heute klicke ich es (das Schloß) in den Einstellungen nur aus. Auch wenn ich mal dann den ingesteckten USB-Stick nicht auf der Arbeitsfläche habe.

Ich verabschiede mich. Bitte um Verständnis.

mfg

mike7

Post Reply

Return to “Deutsches Forum”