[Debconf-devel] Bug#657630: debconf: Silently fails on multi-line values in db_set

Matthijs Kooijman matthijs at stdin.nl
Fri Jan 27 15:08:01 UTC 2012


Package: debconf
Version: 1.5.41
Severity: normal

Hi folks,

after spending quite some time on debugging a nullmailer postinst issue,
I discovered that debconf's db_set chokes when multi-line values are
passed to it (in this particular case, /etc/mailname contained two
lines, and db_set shared/mailname "`cat /etc/mailname`" was called).

I'm not quite sure if multi-line values should be supported (the manual
doesn't seem to mention supporting it, nor requiring that values be
single line).

Right now, if a multiline value is passed to db_set, it simply sends it
over causing debconf to interpret the second line as an invalid command,
breaking the rest of the script (due to a desync in command/responses).
This can be reproduced with the following script (for some reason I
needed to db_get's after the broken db_set, not sure why that is, the
original case used a db_set).

	#!/bin/sh

	. /usr/share/debconf/confmodule

	MULTI='foo
	bar'

	db_get debconf/frontend
	echo $?

	db_set debconf/frontend "$MULTI"
	echo $?

	db_get debconf/frontend
	echo $?

Save this script as "multiline-db_set" and run it using:

	matthijs at grubby:~$ debconf ./multline-db_set 
	debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied
	0
	0
	20
	debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: Permission denied

Note that the first db_get was only added to show that the db_get
normally works (return 0), but as you can see here, the second db_get
returns 20 instead.

Also, you should ignore the permission errors, since I'm not running as
root. Behaviour is the same when running as root, but without the
permission errors.

In any case, I would expect that debconf would (in decreasing order of
preference):

 1. Support multiline values properly. It seems there is a
 debconf-escape command, but looking at the code it's only used for
 return values, not command arguments (I guess this was implemented for
 the metaget command for example, not db_get, then?).
 2. Define that values must be a single line, and show a big fat error
 when a debconf-using script violates this requirement. Possible problem
 here is of course that the debconf-using script isn't usually in a
 position to show errors?
 3. Silently truncate the value to the first line in confmodule, to at
 least prevent the script from silently failing completely.

Of course 1. is preferred, but I suspect that would require invasive
changes. If 2. is not an option for the reasons I suggested, then
perhaps debconf should display the error instead of / in addition to
returning it to the confmodule (Also see #657626 [1], about showing
debug messages for these errors).

Gr.

Matthijs

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657626

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debconf depends on:
ii  perl-base  5.14.2-6

Versions of packages debconf recommends:
ii  apt-utils     0.8.15.9
ii  debconf-i18n  1.5.41

Versions of packages debconf suggests:
ii  debconf-doc                <none>
ii  debconf-utils              <none>
ii  libgtk2-perl               2:1.223-1+b2
ii  libnet-ldap-perl           <none>
ii  libqtcore4-perl            <none>
ii  libqtgui4-perl             <none>
ii  libterm-readline-gnu-perl  <none>
ii  perl                       5.14.2-6
ii  whiptail                   0.52.11-2.1

-- debconf information excluded





More information about the Debconf-devel mailing list