mhogomchungu / zuluCrypt

zuluCrypt is a front end to cryptsetup and tcplay and it allows easy management of encrypted block devices
https://mhogomchungu.github.io/zuluCrypt
Other
513 stars 60 forks source link

Problems with special characters (äöüß) #188

Closed improve-code closed 2 years ago

improve-code commented 2 years ago

Zulucrypt can't handle filenames of containers and file paths which include special characters like ,,ä", ,,ö", ,,ü" and ,,ß" when you want to open a container.

Issue 1:

Instead it shows the � symbol (replacement character) in the Volume path and if so in the mount point name. You can't open an container of that kind.

I don't know whether you plan to fix that.

Issue 2: Only File and not container created, but shown as successful

Problematic is, that zulucrypt however mistakenly seems to be able to create containers (in my case in a new file), which include those characters in the file name or file path. There is no error shown. You can't open the container in that file after renaming the file or moving it to a different path, both without special characters.

I think instead only the file but not the volume is created. But zulucrypt shows – I think falsely – that the volume was successfully created.

Additional information to Issue 1:

You can't open an container of that kind. If only the filename is invalid there is shown the error:

,A non supported device encountered,device is missing or permission denied
Possible reasons for getting the error are:
1. Device path is invalid.
2. The device has LVM or MDRAID signature

Once I had another more specific error shown – maybe with special characters at another place – but I can't reproduce it now.

mhogomchungu commented 2 years ago

Can confirm.

With a image file named volüme.img, zuluCrypt expects the mapper path to be

/dev/mapper/zuluCrypt-500-NAAN-volüme.img-2848233069

but cryptsetup creates a mapper path of

/dev/mapper/zuluCrypt-500-NAAN-vol\\xc3\\xbcme.img-2848233069

The above mismatch causes zuluCrypt to successfully unlock the volume and then lose track of it.

I see two solutions:-

  1. Somehow predict how cryptsetup create mapper path with these characters and do the same in zuluCrypt.
  2. In zuluCrypt, silently drop these characters or somehow match them to ascii character.
  3. Refuse to unlock volumes with these "problematic" characters.
mhogomchungu commented 2 years ago

This is now fixed and i went with substituting non asci characterw with '_' character.

Thanks for the report and sorry for a long wait before i looked into this.

[ink@localhost ~]$ zuluCrypt-cli -o -d volüme.img -m xxx -p xxx
SUCCESS: luks volume opened successfully
volume mounted at: /home/ink/xxx
[ink@localhost ~]$ zuluCrypt-cli -s -d volüme.img
/dev/mapper/zuluCrypt-500-NAAN-vol__me.img-2848233069 is active and is in use.
 type:          luks2
 cipher:        aes-xts-plain64
 keysize:       512 bits
 offset:        32768 sectors / 16.0 MB
 device:        /dev/loop0
 loop:          /home/ink/volüme.img
 mode:          read and write
 active slots:  1 / 32
 file system:   ext4
 total space:   2.7 MB
 used space:    135.0 KB
 free space:    2.6 MB
 used%:         4.86%
 UUID:          "b4c4e77f-7047-4dde-904a-243da89daf44"
 mount point1:  /home/ink/xxx
 mount point2:  Nil
[ink@localhost ~]$ 
improve-code commented 2 years ago

Thank you very much.

If I understand you right, it doesn't affect the filename, just the program intern path. If it is that way, I think everything is ok .

I just want to add that the fourth solution to the initiate problem would have been to achieve a change in cryptsetup.