[linux-lvm] libdevmapper's handling of devices with spaces in the name

[Phillip Susi]

So if I tell dmsetup to create a device named 'foo bar' it ends up
actually naming it 'foo\x20bar'. If I run parted on 'foo\x20bar', it
appears that libdevmapper helpfully tries to unescape the name,
returning 'foo bar' from dm_task_get_name(). Unfortunately, such a
dev node does not actually exist so this creates a problem trying to
open it.

This seems like a bug in libdevmapper. I'd say the name of the actual
dev node should not be escaped in the first place.

[Zdenek Kabelac]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So if I tell dmsetup to create a device named 'foo bar' it ends up
actually naming it 'foo\x20bar'. If I run parted on 'foo\x20bar', it
appears that libdevmapper helpfully tries to unescape the name,
returning 'foo bar' from dm_task_get_name(). Unfortunately, such a
dev node does not actually exist so this creates a problem trying to
open it.
This seems like a bug in libdevmapper. I'd say the name of the actual
dev node should not be escaped in the first place.

This is no longer true for 'modern' systems with udev.

libdevmapper no longer creates any /dev nodes - it's all job for udev.

And udev has had in dark ages the idea to use 'space' as a separator
for device names in device list. Thus it 'invented' escaping/mangling names.
(There are more prohibited characters which used to be used for normal device
names (see man dmsetup mangling))

If you have system without udev - you could disable name mangling on i.e.
dmsetup cmdline.

There is also envvar DM_DEFAULT_NAME_MANGLING_MODE_ENV_VAR_NAME
which could be used to set prefered behavior.

So there is no bug in libdm side - but I'll not comment on the rest...

I'll just note - it really means all tools now would need to be fixed to
handle udev mangled names properly...

Regards

Zdenek

[Phillip Susi]

Post by Zdenek Kabelac
This is no longer true for 'modern' systems with udev.
libdevmapper no longer creates any /dev nodes - it's all job for udev.
And udev has had in dark ages the idea to use 'space' as a
separator for device names in device list. Thus it 'invented'
escaping/mangling names. (There are more prohibited characters
which used to be used for normal device names (see man dmsetup
mangling))
If you have system without udev - you could disable name mangling
on i.e. dmsetup cmdline.

So it is doing this to try and work around a bug in udev. Has this
been fixed in modern udev and should be safe to disable? It doesn't
seem to work for me when I do with udev 204: I end up with
/dev/mapper/foo.

Post by Zdenek Kabelac
There is also envvar DM_DEFAULT_NAME_MANGLING_MODE_ENV_VAR_NAME
which could be used to set prefered behavior.
So there is no bug in libdm side - but I'll not comment on the
rest...

The bug in libdm is that it is lieing to the calling application about
the name of the device, claiming it is not escaped, when in fact, it
is. Or is dm_task_get_name() supposed to return a human readable
string rather than the actual file name? If that is the case, how to
get the actual file name instead?

[Zdenek Kabelac]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Zdenek Kabelac
This is no longer true for 'modern' systems with udev.
libdevmapper no longer creates any /dev nodes - it's all job for udev.
And udev has had in dark ages the idea to use 'space' as a
separator for device names in device list. Thus it 'invented'
escaping/mangling names. (There are more prohibited characters
which used to be used for normal device names (see man dmsetup
mangling))
If you have system without udev - you could disable name mangling
on i.e. dmsetup cmdline.

So it is doing this to try and work around a bug in udev. Has this
been fixed in modern udev and should be safe to disable? It doesn't

Unfortunately this is seen as a 'feature' of udev - so there is no plan to fix
it in udev - since too many other things depends on the current naming logic
(i.e all udev rules scripts written in bash would need major fixes to work
with characters which are nontrivil to work with)
All surrounding Gnome above it as well - you would be really amazed if you
would check this deeply...

seem to work for me when I do with udev 204: I end up with
/dev/mapper/foo.

Post by Zdenek Kabelac
There is also envvar DM_DEFAULT_NAME_MANGLING_MODE_ENV_VAR_NAME
which could be used to set prefered behavior.
So there is no bug in libdm side - but I'll not comment on the rest...

The bug in libdm is that it is lieing to the calling application about
the name of the device, claiming it is not escaped, when in fact, it
is. Or is dm_task_get_name() supposed to return a human readable
string rather than the actual file name? If that is the case, how to
get the actual file name instead?

As said - there is no bug in libdm - libdm expects udev to create nodes.
You can reconfigure libdm to do this job instead of udev - but then nothing
else will work with it - so it's basically dead-road...

The best you can do is to not use names which needs mangling - that's my best
suggestions (and lvm team already spend countless hours on some usable
workarounds and solutions...)

For mangling see 'dmsetup mangle' help - how to obtain device names...

Zdenek

[Phillip Susi]

Post by Zdenek Kabelac
As said - there is no bug in libdm - libdm expects udev to create
nodes. You can reconfigure libdm to do this job instead of udev -
but then nothing else will work with it - so it's basically
dead-road...

It doesn't matter who creates it, what matters is that when parted
asks what the correct name is, that it be told the name that actually
is created.

Post by Zdenek Kabelac
The best you can do is to not use names which needs mangling -
that's my best suggestions (and lvm team already spend countless
hours on some usable workarounds and solutions...)

Unfortunately, it seems that a number of hardware vendors ship
preconfigured fakeraid setups with a space in the name of the volume.

Post by Zdenek Kabelac
For mangling see 'dmsetup mangle' help - how to obtain device
names...

Is there a libdevmapper call to do this?

[Zdenek Kabelac]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Zdenek Kabelac
As said - there is no bug in libdm - libdm expects udev to create
nodes. You can reconfigure libdm to do this job instead of udev -
but then nothing else will work with it - so it's basically
dead-road...

It doesn't matter who creates it, what matters is that when parted
asks what the correct name is, that it be told the name that actually
is created.

I assume you will need to learn why it does matter - it's the crucial part of
this puzzle - but it's surely not a topic for lvm-devel list.

And as I've also already said - yes it really does mean that many userspace
tools need be adapted to handle things in more user friendly way.

Post by Zdenek Kabelac
The best you can do is to not use names which needs mangling -
that's my best suggestions (and lvm team already spend countless
hours on some usable workarounds and solutions...)

Unfortunately, it seems that a number of hardware vendors ship
preconfigured fakeraid setups with a space in the name of the volume.

It have to be dealt with them properly on user level part.
User level needs to use some different names for such devices.

It's currently highly discouraged to create devices with 'prohibited'
characters in them - since the rest will fail to process them properly.

You really can't expect udev will start to support spaces in names....
So tools like 'mount' will need to know how to translate...

Post by Zdenek Kabelac
For mangling see 'dmsetup mangle' help - how to obtain device
names...

Is there a libdevmapper call to do this?

https://git.fedorahosted.org/cgit/lvm2.git/tree/libdm/libdevmapper.h

Look for 'mangle' in function names.

For 'howto' look at dmsetup.c source code:

https://git.fedorahosted.org/cgit/lvm2.git/tree/tools/dmsetup.c

There is not much better doc for these function unfortunately.
I'd strongly advise to stay on 'dmsetup' level of usage.

It would also probably help to describe what kind of app which uses
libdevmapper you are trying to develop...

Regards

Zdenek

[Phillip Susi]

Post by Zdenek Kabelac
It would also probably help to describe what kind of app which
uses libdevmapper you are trying to develop...

I'm trying to fix parted to not fail on such devices. As I said
originally it fails because it calls dm_task_get_name() to find out
the true /dev/mapper/ name of the device, so that it can add the
partition number to it and be able to open the partition. Now that I
look at the comment in the headers, it sounds like perhaps it just
should be using dm_task_get_name_mangled() instead.

I'm also still wondering why udev can't simply handle quoted names
with spaces in them. People have been dealing with this sort of thing
in shell for years...

[Alasdair G Kergon]

Post by Phillip Susi
I'm also still wondering why udev can't simply handle quoted names
with spaces in them. People have been dealing with this sort of thing
in shell for years...

Once you've had exposure to udev you soon learn that "wondering why" gets
you nowhere:) However bizarre, your only option is to conform.
Name mangling in lvm2/device-mapper was designed both to conform and
to still allow for all possibilities in as transparent a way as we could.

The primary new limitation is a reduction in the effective maximum length
of a device name due to the quoting. If this becomes a problem we will have
to extend the kernal API to support longer names.

Alasdair

[Peter Rajnoha]

Post by Phillip Susi
I'm also still wondering why udev can't simply handle quoted names
with spaces in them. People have been dealing with this sort of thing
in shell for years...

We tried that: https://bugzilla.redhat.com/show_bug.cgi?id=736486#c12

And this was not the only request from us to fix something in udev.
But based on previous experience, we concluded that it was just useless
to try spending time with persuading the other side.

If you have enough nerves to argue with them, I'm really and sincerely
wishing you good luck.

[Peter Rajnoha]

Post by Phillip Susi
I'm trying to fix parted to not fail on such devices. As I said
originally it fails because it calls dm_task_get_name() to find out
the true /dev/mapper/ name of the device, so that it can add the
partition number to it and be able to open the partition. Now that I
look at the comment in the headers, it sounds like perhaps it just
should be using dm_task_get_name_mangled() instead.

Yes, you can call that fn to get the name in its actual "mangled" form
as it appears in /dev/mapper.