* Re: Whitespaces in ID_VENDOR and ID_MODEL
2009-01-05 22:26 Whitespaces in ID_VENDOR and ID_MODEL Marcel Holtmann
@ 2009-01-05 22:59 ` Kay Sievers
2009-01-05 23:37 ` Marcel Holtmann
2009-01-06 0:24 ` Kay Sievers
2 siblings, 0 replies; 4+ messages in thread
From: Kay Sievers @ 2009-01-05 22:59 UTC (permalink / raw)
To: linux-hotplug
On Mon, Jan 5, 2009 at 23:26, Marcel Holtmann <marcel@holtmann.org> wrote:
> so I was playing with adding environment variables to devices in the
> udev database for later easy enumeration. And I like having ID_VENDOR
> and ID_MODEL available and would like to extend this even to PCI and
> SDIO in the future, but why are all whitespace replaced with "_".
> E: ID_VENDOR=Novatel_Wireless
> E: ID_MODEL=Novatel_Wireless_HSUPA_Modem
> E: ID_REVISION\000
> E: ID_SERIAL=Novatel_Wireless_Novatel_Wireless_HSUPA_Modem_356846015115701
Yeah, all strings in usb_id are mangled to be used in symlink names.
Like all the other *_id tools do too. When we started doing that,
nobody thought we would ever use these strings for anything else than
creating symlinks. :)
Some of the values, like ATA and SCSI just fill the whole remaining
string buffer with whitespaces, which need to be stripped too, to be
used in symlinks.
For stuff that needs to be reversible, like filesystem label strings,
which can contain any char, need to be valid and safe chars to be a
symlink, and we need to be able to translate the name back to the
original value, we encode the string with url encoding, like:
ID_FS_LABEL=/
ID_FS_LABEL_ENC=\x2f
We need to sanitize the values at least for things like newline,
quoting and other control chars, because most of these values are
completely "untrusted userdata", and a fake device with a usb model
string like "Foo\nBAR=1" we don't want to import unmangled. :)
If you have an idea what we should do/change to make these values more
useful, let me know.
Kay
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Whitespaces in ID_VENDOR and ID_MODEL
2009-01-05 22:26 Whitespaces in ID_VENDOR and ID_MODEL Marcel Holtmann
2009-01-05 22:59 ` Kay Sievers
@ 2009-01-05 23:37 ` Marcel Holtmann
2009-01-06 0:24 ` Kay Sievers
2 siblings, 0 replies; 4+ messages in thread
From: Marcel Holtmann @ 2009-01-05 23:37 UTC (permalink / raw)
To: linux-hotplug
Hi Kay,
> > so I was playing with adding environment variables to devices in the
> > udev database for later easy enumeration. And I like having ID_VENDOR
> > and ID_MODEL available and would like to extend this even to PCI and
> > SDIO in the future, but why are all whitespace replaced with "_".
>
> > E: ID_VENDOR=Novatel_Wireless
> > E: ID_MODEL=Novatel_Wireless_HSUPA_Modem
> > E: ID_REVISION\000
> > E: ID_SERIAL=Novatel_Wireless_Novatel_Wireless_HSUPA_Modem_356846015115701
>
> Yeah, all strings in usb_id are mangled to be used in symlink names.
> Like all the other *_id tools do too. When we started doing that,
> nobody thought we would ever use these strings for anything else than
> creating symlinks. :)
for things like ID_SERIAL this makes sense to me. For ID_VENDOR and
ID_MODEL not so much. Does udev itself use these values anywhere? Or can
we have udev just do the stripping part and have *_id tools return the
plain values?
> Some of the values, like ATA and SCSI just fill the whole remaining
> string buffer with whitespaces, which need to be stripped too, to be
> used in symlinks.
>
> For stuff that needs to be reversible, like filesystem label strings,
> which can contain any char, need to be valid and safe chars to be a
> symlink, and we need to be able to translate the name back to the
> original value, we encode the string with url encoding, like:
> ID_FS_LABEL=/
> ID_FS_LABEL_ENC=\x2f
>
> We need to sanitize the values at least for things like newline,
> quoting and other control chars, because most of these values are
> completely "untrusted userdata", and a fake device with a usb model
> string like "Foo\nBAR=1" we don't want to import unmangled. :)
>
> If you have an idea what we should do/change to make these values more
> useful, let me know.
I agree that we need to do at least some kind of sanitization, but for a
lot of these values having the clear text strings available would be
really nice. Especially the ID_VENDOR and ID_MODEL strings. If udev is
having access to these string (like for USB or when creating unique
symlinks) anyway, then it makes no sense to not duplicate the logic to
these from the device.
Do you ever defined a character set for the environment values? It would
be nice if it UTF-8, because then we can copy most values natively.
Regards
Marcel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Whitespaces in ID_VENDOR and ID_MODEL
2009-01-05 22:26 Whitespaces in ID_VENDOR and ID_MODEL Marcel Holtmann
2009-01-05 22:59 ` Kay Sievers
2009-01-05 23:37 ` Marcel Holtmann
@ 2009-01-06 0:24 ` Kay Sievers
2 siblings, 0 replies; 4+ messages in thread
From: Kay Sievers @ 2009-01-06 0:24 UTC (permalink / raw)
To: linux-hotplug
On Tue, Jan 6, 2009 at 00:37, Marcel Holtmann <marcel@holtmann.org> wrote:
>> > so I was playing with adding environment variables to devices in the
>> > udev database for later easy enumeration. And I like having ID_VENDOR
>> > and ID_MODEL available and would like to extend this even to PCI and
>> > SDIO in the future, but why are all whitespace replaced with "_".
>>
>> > E: ID_VENDOR=Novatel_Wireless
>> > E: ID_MODEL=Novatel_Wireless_HSUPA_Modem
>> > E: ID_REVISION\000
>> > E: ID_SERIAL=Novatel_Wireless_Novatel_Wireless_HSUPA_Modem_356846015115701
>>
>> Yeah, all strings in usb_id are mangled to be used in symlink names.
>> Like all the other *_id tools do too. When we started doing that,
>> nobody thought we would ever use these strings for anything else than
>> creating symlinks. :)
>
> for things like ID_SERIAL this makes sense to me. For ID_VENDOR and
> ID_MODEL not so much. Does udev itself use these values anywhere?
I don't think the usb_id keys are used, but the same key names are
used directly from ata_id and scsi_id.
> Or can
> we have udev just do the stripping part and have *_id tools return the
> plain values?
We need to sanitize some chars in any case, and the question is how
far you go here, do we allow $, backticks, backslash, quotes, and such
things? It get's pretty difficult how to decide what "plaintext" is in
that context.
All the values are from completely untrusted sources. Everybody can
put any string in a fake USB device, and we would copy these strings
in the environment of processes/shell scripts running as root. That's
why we need to be very careful here.
>> Some of the values, like ATA and SCSI just fill the whole remaining
>> string buffer with whitespaces, which need to be stripped too, to be
>> used in symlinks.
>>
>> For stuff that needs to be reversible, like filesystem label strings,
>> which can contain any char, need to be valid and safe chars to be a
>> symlink, and we need to be able to translate the name back to the
>> original value, we encode the string with url encoding, like:
>> ID_FS_LABEL=/
>> ID_FS_LABEL_ENC=\x2f
>>
>> We need to sanitize the values at least for things like newline,
>> quoting and other control chars, because most of these values are
>> completely "untrusted userdata", and a fake device with a usb model
>> string like "Foo\nBAR=1" we don't want to import unmangled. :)
>>
>> If you have an idea what we should do/change to make these values more
>> useful, let me know.
>
> I agree that we need to do at least some kind of sanitization, but for a
> lot of these values having the clear text strings available would be
> really nice. Especially the ID_VENDOR and ID_MODEL strings. If udev is
> having access to these string (like for USB or when creating unique
> symlinks) anyway, then it makes no sense to not duplicate the logic to
> these from the device.
Yeah, but as mentioned, we need to be careful and will need to mangle
quoting and newlines at least. Some vendor values are known to contain
single quotes, which we probably should not copy unmangled to an
environment key.
> Do you ever defined a character set for the environment values? It would
> be nice if it UTF-8, because then we can copy most values natively.
We don't do any transcoding or anything else here, we allow plain
ascii [a-zA-Z0-9] and "#+-.:=@_" and also valid utf8 to pass
unmangled, everything else gets replaced or encoded.
Should we add encoded versions of these values, to be safe? Like
ID_VENDOR_ENC and ID_VENDOR_MODEL_ENC? The consumer of these strings
would need to translate "%xx" back to the char value, like we do for
the filesystem labels, and free-text uuids today.
Kay
^ permalink raw reply [flat|nested] 4+ messages in thread