Bug 834734 - Luks doesn't do spaces right.
Luks doesn't do spaces right.
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cryptsetup-luks (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Milan Broz
Release Test Team
Depends On:
  Show dependency treegraph
Reported: 2012-06-22 23:08 EDT by LunaSilverMoon
Modified: 2013-02-28 23:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-25 03:48:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description LunaSilverMoon 2012-06-22 23:08:28 EDT
Description of problem:
When open a luks encryption specifying the name of the partition.  If used with as this "Support Mouse" in the /dev/mapper it comes out /dev/mapper/Support\x20Mouse.  Unforunatly this does not work correctly either trying to mount it in a directory for example /dev/mapper/"Support Mouse".  It would say not found.  Correct way to do it /dev/mapper/"Support\x20Mouse"

Version-Release number of selected component (if applicable):

How reproducible:
Open a encrypted partition give it a name that has a space in quotes.
cryptsetup luksOpen /dev/Support_Mouse_vg/LogVol06 "Support Mouse"

Steps to Reproduce:
1. cryptsetup luksOpen /dev/namofencryptedpartition "A name with spaces and quotes"
Actual results:

Expected results:
/dev/mapper/Support Mouse

Additional info:
Comment 2 Milan Broz 2012-06-23 04:42:29 EDT
This is udev/DM limitaton, you cannot create device name with spaces in /dev.

Just try dmsetup create "a b c" --table "0 8 zero". It will create the same problem. 

All I can do is to disable such names in cryptsetup completely.
Comment 3 Alasdair Kergon 2012-06-23 06:36:29 EDT
If you want to use spaces as input, you must also use the udev escaping rules elsewhere in your script.  'dmsetup mangle' can do this conversion for you.

       mangle [device_name]
              Ensure existing device-mapper device name is in the correct man‐
              gled form containing only whitelisted characters  (supported  by
              udev)  and  do  a  rename if necessary. Any character not on the
              whitelist will be mangled based on the --manglename settting.

       --manglename <mangling_mode>
              Mangle any character not on a whitelist using mangling_mode when
              processing  device-mapper device names. The names are mangled on
              input and unmangled on output where the mangling_mode is one of:
              none  (no mangling), hex (always do the mangling) and auto (only
              do the mangling if not mangled yet, do nothing if  already  man‐
              gled,  error  on  mixed;  this  is  used by default).  Character
              whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also  sup‐
              ported  by  udev.  Any  character not on a whitelist is replaced
              with its hex value (two digits) prefixed by \x.
Comment 4 LunaSilverMoon 2012-06-23 17:49:51 EDT
I did not know this was a limitation but before the upgrade 6.3 it worked fine without no problems.  I'll adjust scripts from what Alasdair Kergon said  about dmsetup mangle.
Comment 5 Alasdair Kergon 2012-06-23 18:35:20 EDT
In short:

a)  udev owns /dev now;

b)  udev only allows its whitelisted characters to be present in /dev;

c)  any other characters are "mangled" according to that formula;

d)  anything *directly* using /dev may need to be aware of udev mangling;

e)  device-mapper-based tools handle this transparently using libdevmapper so that users can continue to use non-conforming names in such tools.
Comment 6 Peter Rajnoha 2012-06-25 03:44:41 EDT
I think the problem here is that when using "Support Mouse" on cryptsetup input, it gives you a "Support\x20Mouse" in /dev/mapper which is perfectly fine - this conversion is done by libdevmapper. Otherwise, udev can't deal with such names (without this conversion, udev would assume these are two separate names, separated by a space so you would end up with "/dev/mapper/Support" and "/dev/mapper/Mouse" which is not what you would expect).

Working with such device name shold work fine, BUT you have to count with bash escaping (or whichever you use), so:

[1] rawhide/~ # cryptsetup luksOpen /dev/sda "Support Mouse"
Enter passphrase for /dev/sda: 

[1] rawhide/~ # ls /dev/mapper/
Support\x20Mouse  control

[1] rawhide/~ # mount /dev/mapper/Support\\x20Mouse /mnt/temp/

[1] rawhide/~ # df -h /mnt/temp/
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/Support\x20Mouse  125M  7.8M  111M   7% /mnt/temp

See the \\x20 - that's because you need to count with sh escaping as well! This is not bug imho.

And yes, if you have any existing device-mapper devices on your system without such mangling used (for example, if you have not rebooted your system, but you upgraded to that newer version of libdevmapper that supports mangling - libdevmapper v1.02.71/lvm2 v2.02.92), you should use "dmsetup mangle" command to translate these names as already advised in comment #3.
Comment 7 Milan Broz 2012-06-25 03:48:03 EDT
In RHEL5 it works, because libdevammper  (which is cryptsetup based on) create nodes without udev interference.

In early RHEL6 releases it can perhaps create name with space because of direct node creation fallback (libdevampper checks if node was created by udev and if not, it "fixes" it). This is bug (or misconception), not feature :)

Once libdevamapper started to use proper device name mangling, this fallback never applies - and you see the change here.

Cryptsetup cannot do anything here, it depends what is device-mapper library doing - if you think it is a bug, report bug against udev or device-mapper library (also see bug #736486).
Comment 8 Peter Rajnoha 2012-06-25 03:51:57 EDT
(In reply to comment #7)
> Cryptsetup cannot do anything here, it depends what is device-mapper library
> doing - if you think it is a bug, report bug against udev or device-mapper
> library (also see bug #736486).

Report against udev, please - libdevmapper can't do anything else with this problem as well if udev is used :)
Comment 9 Peter Rajnoha 2012-06-25 03:59:05 EDT
There's also a request to document this encoding in udev man page (which is, unfortunately, still not there yet): bug #790321. (this is the official encoding that udev supports to escape names with blacklisted characters)

Note You need to log in before you can comment on or make changes to this bug.