kern/149762: volume labels with rogue characters

[jhell]

The following reply was made to PR kern/149762; it has been noted by GNATS.

From: jhell <jhell at DataIX.net>
To: Oliver Fromme <olli at lurza.secnetix.de>
Cc: bug-followup at freebsd.org
Subject: Re: kern/149762: volume labels with rogue characters
Date: Thu, 19 Aug 2010 11:42:32 -0400

 On 08/19/2010 07:29, Oliver Fromme wrote:
 > jhell <jhell at dataix.net> wrote:
 >  >  This is a hack, something that you would commonly find in Linux code and
 >  >  is neither a proper or viable workaround for the naming of labels.
 >  >  
 >  >  Instead, using glabel(8) the admin/user can create a local label to
 >  >  FreeBSD that does not change the original nor does it carry over to any
 >  >  other OS that does not understand geom_label's.
 > 
 > There are cases were you cannot create a permanent label
 > with glabel.  For example, there are quite a lot of USB
 > devices that insist on having their memory formatted with
 > their own firmware only, destroying any other labels.
 > I own an mp3 player (Medion) that behaves like this.
 > The submitter mentioned a digital camera (Nikon, I think)
 > in a previous thread.
 > 
 > How do you suggest to solve the problem for those cases?
 > 
 >  >  Stripping characters no matter what they are with a sysctl is overkill
 >  >  and does not scale well, all the while - presenting false information to
 >  >  the user.
 > 
 > I don't think there is a scalability issue, because it is
 > only done once when a device is attached.  On the other
 > hand, maybe the patch should be changed so it doesn't
 > touch the name at all when the sysctl is 0, so the default
 > behaviour would be no different from what we have today.
 
 If this is the case then why adapt geom_label at all ? why not instead
 go straight for the culprit "devfs/devd" and add a sysctl for stripping
 what needs to be stripped ?. This way it is distinct to /dev and can be
 done on the system-wide basis and/or focused on particular pieces of the
 system like geom_label. This is more of what I meant by scalable.
 
 > 
 >  >  I would highly advise against this. If the user does not like
 >  >  the label that appears in msdosfs/{LABEL} then they are free to change
 >  >  that at their own will.
 > 
 > Unfortunately they are subject to the will of their devices,
 > see above.  And if the device's own label contains a space
 > (the Nikon camera mentioned above does), it cannot be used
 > as-is in /etc/fstab.
 
 That is understandable but to adjust the code to fit a few edge cases
 like this IMO just feels wrong, remember this is only my opinion in this
 case.
 
 > 
 > I think a similar problem occurs with the volume names of
 > CD-ROMs and DVD-ROMs, which contain spaces quite often,
 > and you cannot glabel them.  But I haven't looked deeply
 > into this, maybe it's not an issue.
 > 
 > (Does FreeBSD even support mounting CDs by their volume
 > name, like Solaris does?  I've never tried, but it would
 > come in handy, because I have a clip art CD that I use
 > every now and then, and I never remember whether it's in
 > drive cd0 or cd1 currently ...)
 
 Yes it does.
 
 I usually turn these off for client systems as I find them very unneeded
 and duplicate cases that can cause hell on hald(8). Design flaw of
 hald(8)? no but we introduced it.
 
 kern.geom.label.ext2fs.enable=0
 kern.geom.label.iso9660.enable=0
 kern.geom.label.msdosfs.enable=0
 kern.geom.label.ntfs.enable=0
 kern.geom.label.reiserfs.enable=0
 kern.geom.label.ufs.enable=0
 kern.geom.label.ufsid.enable=0
 kern.geom.label.gptid.enable=0
 kern.geom.label.gpt.enable=0
 
 > 
 >  >  I see presenting the label as it is to the user
 >  >  ``important''.
 > 
 > Uhm ...  it is not my impression that the names of nodes
 > in /dev are intended to present accurate "external"
 > information to the user.  I always thought that the
 > purpose of /dev is an interface between userland software
 > and drivers, and that users shouldn't have to deal with
 > /dev at all during "normal operations".  Am I wrong?
 
 No you are not wrong. But in the case of first introduction of the
 device and the use of fstab(5) being mentioned already, the user has to
 interact with /dev right ?
 
 > 
 > I mean, there are commands to display the atual labels if
 > you need to see them (and I don't mean "ls /dev/...").
 > 
 
 Right I agree with this to an extent that the hypothetical user should
 not have to drop back to a manual page to find out how to get the
 original information of the device.
 
 
 Regards,
 
 -- 
 
  jhell,v