Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Debian Traffic #21 For 1 Feb 2001

Editor: Zack Brown

By Prashanth MundkurSteve Robbins  and  Zack Brown

Debian Home Page | Weekly News | Social Contract | Constitution | Policy Manual | Developer's Reference | Documentation Project | debian-devel Archives

Table Of Contents


Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.

Mailing List Stats For This Week

We looked at 778 posts in 2832K.

There were 271 different contributors. 137 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Configuration Using debconf

14 Jan 2001 - 25 Jan 2001 (63 posts) Archive Link: "use and abuse of debconf"

Summary By Prashanth Mundkur

People: Joey HessMatt Zimmerman

Joey Hess ranted about the current package configuration in Debian:

It has recently come to my attention that several developers are using debconf as an excuse to write a quick hack rather than doing things right. In particular I am talking about several packages that use debconf to prompt the user for information, then write the information to a file in /etc, and when upgraded or reconfigured, clobber any manual changes to the file (and no, I'm not just talking about lilo).

As the author of debconf, this disgusts and saddens me. Debconf was meant to make it easier to do things right, not to entice people to write bad code. Red Hat has made a very bad name for itself amoung knowledeable linux users by providing configuration tools that ignore a sysadmin's manual changes to config files and that stomp over those changes. Debian cannot go down this path; doing so would be a violation of our tradition of quality and of doing the right thing.

He proceeded to give a detailed example on the right way of preserving admin changes to a configuration file.

A lot of interesting discussion ensued, mainly around the use of XML to handle configuration files.

The basic issue is around Debian policy not allowing "conffiles" (used in the Debian sense) to be edited from maintainer scripts. Matt Zimmerman provided a review, before providing a list of options for maintainers:

Herein lies the problem, as I see it. This is a common policy violation because maintainers often want this functionality, but it clashes with policy, or is not addressed. With old-style use of conffiles, package maintainers simply provided a default conffile, which they could update from time to time, and the USER was responsible for merging in their local changes. This was easy on package maintainers, but hard on users.

Some packages cannot supply a reasonable default configuration for all users, and/or would like to make the user's life easier by asking a few questions and generating a configuration file. In the pre-debconf era, this would be done by a <package>config script, a la exim or magicfilter. Once the config file was generated, it would be left alone forever. The user could reconfigure at any time by running the script. If the config file format changed or some such, the user is responsible for re-running the config script and generating a new config file.

In this age of debconf, we now have standard tools for asking the user questions (debconf) and reconfiguring a package (dpkg-reconfigure). In order to use these mechanisms successfully, we need some way to peacefully coexist with the user's manual changes. The key change is that package configuration via these tools is done _by maintainer scripts_, rather than by supplying a default conffile or running a script. Policy specifically forbids the editing of conffiles by maintainer scripts ([1] (must not), [2] (should not)).

Joey later detailed the actual workings of debconf in various situations:

Scenario A: debconf not set to re-ask questions; initial install

* config script skips nonexistant /etc file
* config script asks question  
* admin changes value
* config script updates debconf database
* unpacking happens
* config script gets called by postinst
* config script skips nonexistant /etc file
* config script doesn't re-ask the question
* postinst writes out admin's answer

Scenario B: debconf set to re-ask questions; initial install

* config script skips nonexistant /etc file
* config script asks question
* admin changes value
* config script updates debconf database
* unpacking happens
* config script gets called by postinst
* config script skips nonexistant /etc file
* config script re-asks question                (different from above A)
* admin changes value  
* postinst writes out admin's answer

Scenario C: debconf set to not re-ask questions; upgrade

* config script reads /etc file
* config script doesn't re-ask the question
* unpacking happens  
* config script gets called by postinst  
* config script reads /etc file
* config script doesn't re-ask the question
* postinst writes out value that was read in from /etc file

Scenario C: debconf set to re-ask questions; upgrade

* config script reads /etc file
* config script doesn't re-ask the question (because debconf is smart about this)
* unpacking happens
* config script gets called by postinst
* config script reads /etc file
* config script asks question
* admin changes value
* postinst writes out admin's answer

Scenadio D: reconfiguring the package

* config script reads /etc file
* config script re-asks the question since this is a reconfiguration
* admin changes value
* config script updates debconf database
* postinst is run. It does NOT re-run the config script
* postinst writes out admin's answer

2. Secure Mounting In Linux And The Hurd

19 Jan 2001 - 27 Jan 2001 (21 posts) Archive Link: "user can't mount loop device..."

Summary By Prashanth Mundkur

People: Daniel JacobowitzGoswin BrederlowNeal H WalfieldMarcus BrinkmannNeal WalfieldDale Scheetz

An attempt by Dale Scheetz to mount a /dev/loopN loopback device (which are used to mount filesystems not associated with block devices, using the losetup(8) command) spawned a discussion of the security implications of the users' ability to do this. Dan Jacobowitz thumped the table:

What no one has mentioned is that users absolutely MUST NOT be allowed to run losetup (or mount, which would also be necessary). It's a file image. It can, for instance, contain suid binaries, not owned by the user. That's easy to make - see debugfs.

If you really want to, you could add fstab entries marked 'user,nosuid,nodev' at the least, and provide a wrapper for losetup. As a whole this is a very bad idea, since access to a raw filesystem device often allows for all sorts of system corruption.

Goswin Brederlow provided an example:

If losetup is setuid you could do the following (untested):

losetup /dev/loop/0 /etc/shaddow

and then

dd if=/dev/loop/0 of=passwd

Nice. :)

Several folks pointed out that the Hurd would handle this differently. Neal Walfield demonstrated The Hurd Way(TM):

The reason that Linux, and other monolithic kernels, do not allow users to mount filesystems is that a bad filesystem can crash the kernel. In the hurd, all of these pieces of the system live outside of the kernel and run as the user that starts them. If a user has access to a node, e.g. $HOME/fs-image, they can translate it into the file system:

# cd
# settrans -ac fs /hurd/ext2fs fs-image
# cd fs
# ls
file1 file2 dir1
# pwd

If the translator were to die due to a faulty image or for any other reason, it would effectively receive a SIGSEGV and die like any other user space program.

Marcus Brinkmann elaborated:

The reason is that authentication can be handled in a superior way: Filesystems live as user space programs, and permissions are not leaked to the parent processes (so if you run a filesystem as user joe, you can't get more permissions that user joe can get, regardless of the filesystems content).

It goes even further: You can boot a new (sub)hurd system from within a disk image owned by you. In this sub-system, you appear to be the user root (and every user you want to be). But still no permissions leak to the parent hurd.

3. Shifty dselect Tips

21 Jan 2001 - 25 Jan 2001 (21 posts) Archive Link: "dpkg-dev-emacs vs. debian-changelog-mode vs..."

Summary By Prashanth Mundkur

People: Henrique M HolschuhSteve GreenlandChristoph Simon

In the midst of other discussion, Henrique M Holschuh railed against the obnoxious behaviour of dselect:

dselect keeps pissing me off trying to install all sort of crap I don't want because of Suggests, but *this is a bug in dselect*.

We should be able to simply mark a package as in 'hold' 'uninstalled' 'purge' state and dselect should respect that and do not try to change the purge to 'install' because of a Suggests.

Steve Greenland corrected Henrique, "Since when does it do this? I've never seen such behaviour. Now, of course, if you meant "Recommends" instead of "Suggests", you're absolutely right."

On how to make dselect remember purge settings between sessions, Christoph Simon provided: "you can manually de-select the packages you don't want (underscore or minus) and exit with shift-Q" .

Steve Greenland added:

Yes this works (and I'll note the very useful key shift-R, which restores the settings the what the user actually set, rather than having to go through them all one-by-one), but you have to do this EVERY FSCKING TIME YOU USE DSELECT! Dselect should only check Recommends (and Suggests) when the user changes the status of the package containing the Recommends (and Suggests). Or, at most, when the package version changes (and the package is not on hold).

Of course, people have been wanting this for years, and it's never been done. In defense of the dpkg maintainers, I haved looked at the code, and it's a non-trivial problem, because the checking of Recommends and Suggests is wrapped up with the Depends/Conflicts, which does need to be checked every time. R and S checking would need to be split out, which wouldn't be easy.

4. Resolution Of Package Namespace Collision

19 Jan 2001 - 24 Jan 2001 (9 posts) Archive Link: "Assistance required for namespace clash"

Summary By Zack Brown

People: Mark BakerMarco d'ItriCraig SmallJacob Kuntz

Craig Small, maintainer of the procps package, reported that the latest version included a 'pgrep' binary, which clashed with the 'pgrep' binary in the 'pgrep' (perl compatible grep) package. He said that one of the packages had to change the binary's name, and that he was willing to be the one; although 'pgrep' was a relatively standard name, as used in some Solarises. He asked for suggestions for new names. Marco d'Itri felt that if the name had been standardized elsewhere, it shouldn't be changed in Debian; but there was no reply. Jacob Kuntz felt that the binary that had been in common use for the shortest time should be the one to change. There was no reply. Karsten M. Self favored 'procgrep', if Craig had to change the name. He said that something like 'psgrep' would be ambiguous, since it might suggest grepping through 'ps' output. Further discussion showed this to be true, as folks weren't sure whether Karsten meant PostScript output or the output from the 'ps' program.

However, Mark also added, "But it doesn't matter anyway. The PCRE grep program formerly known as pgrep was renamed upstream to pcregrep some time ago, I just kept a link to it in the debian package under the old name. I'll change that and let you keep the standard name for the process grep one." Craig was very happy, as this would allow him to clear out several bug reports filed against his package; and asked Mark to let him know when the change had been uploaded. Mark replied, "Just uploaded now. You should make your package conflict with versions of pgrep less than 3.3-5." End Of Thread (tm).

5. Ill-Advised Optimization

22 Jan 2001 - 24 Jan 2001 (21 posts) Archive Link: "Migration to Pentium?"

Summary By Steve Robbins

People: Harald DunkelSteve GreenlandWichert Akkerman

Every few months, someone asks the why there are no packages optimized for pentiums. This month, it was Harald Dunkel. " I would like to make the suggestion to establish a 'i586' tree of the Debian binaries for Sid. This tree should be built using the appropriate compiler flags to benefit from the improved technology of the last years. "

The concensus of the replies is that the cost in disk space (master site and mirrors), bandwidth (updating mirrors), and time is not justified by modest gain in speed. Though Harald pointed to a claim of 10%-30% gain in speed, Wichert Akkerman says proof of the speedup has never been furnished. Moreover, according to Sean, " a pentium optimized binary will run slower on a P6 chip (PPro, PII, PIII, Celeron I, Celeron II). "

Several posts in the thread touched on ways to standardize building of optimized packages. In addition to CPU optimizations, this may be helpful with packages that can take advantage of MMX or 3DNow! hardware. One proposal, suggested by Steve Greenland, is that packages " could to provide an extra-target in their debian/rules file that detects if they are running on CPU that will benefit special compile-time options and use those options for a new binary package. "

Giving it a general name such as "binary-opt" would make using such a package fairly quick to acquire:

$ apt-get source foo
$ (cd foo-x.y; fakeroot debian/rules binary-opt)
$ sudo dpkg -i foo*.deb

(I would submit that if the supposed benefits of such a optimized build don't justify the effort of typing three commands, then they *certainly* don't justify the effort of maintaining a whole new distribution. :-))

6. Maintainer Qualifications

23 Jan 2001 - 25 Jan 2001 (6 posts) Archive Link: "Re: Security upgrade for potato by new major version and distro change?"

Summary By Zack Brown

People: Christian HammersManoj SrivastavaElegant DiceJosip Rodin

In the course of discussion, Christian Hammers advocated:

Debian has many maintainers who cannot programm or like me can programm perl and php (well enough to get paid for) it but have not much experience with C.

Those people can do nothing about a c++ security fix except crying out loud for help.

Manoj Srivastava replied:

If the maintainer does not know C/C++, then they really have no business packaging a C/C++ programme. Debian is supposed to be more than a repository of everything out there (or a cool email address). It is also supposed to be about quality. If you do not understand the language your package is written in, it is highly unlikely your stewardship of that package is goging to be anything but mediocre.

I would hope most developers would realize this, and do the right thing

Josip Rodin agreed in the general case, but added that some package problems were simply very difficult, and a maintainer should not be expected to understand all the difficult aspects of a package's internals and how to fix them. Manoj replied:

Let me reiterate that I was in no way implying that debian developers are in dire need of having god hood conferred on them, and they are by no means omniscient, and thus indeed need help in solving problems from time to time.

I was merely commenting that familiarity with the language your package be written in be a minimal requirement, since with out that you may not even be able to evaluate the help you get (not to mention making it more, umm, tiresome, for people to help you).

Elegant Dice had a different opinion. He said:

I'm sorry manoj, I don't agree with you there. Surely the maintainer is there to ensure that the program in its existing state is packaged and can be installed on a computer correctly, and to work as it should. This means configuration issues should be a maintainer's biggest issue they must deal with.

The debugging of a package's program is not solely the responsibility of the maintainer, rather in the Linux(and others)/GNU arena, the user is the one who takes responsibility for the program's actual performance. If a maintainer cannot debug a program, he can simply redirect issues upstream.

Manoj replied:

You have a strange view of the resposibilities of a Debian developer. Developers are far more than glorified packagers, they are responsible for ensuring that their packages fit policy (including ensuring the config files are looked for in /etc; closing any /tmp race bugs).

If you do not know the language your packages are coded in, you can't make improvements (you didn't just think we get towards the best possible distribution by merely packaging things, did you); you can't handle the bug reports, you can't even evaluate the patches submitted to you. And a cleless maintainer is no help for upstream.

There was no reply.

7. Debian BSD?

24 Jan 2001 (6 posts) Subject: "Debian GNU/BSD* ?"

Summary By Steve Robbins

People: Felipe Alvarez HarneckerPeter Makholm

Another repeat question this week comes from Felipe Alvarez Harnecker, who wondered about plans to Debianize one of the BSD strains. " I't would be great to have alternatives to Linux despite i'm a Linux fan. " Peter Makholm noted " This question pops up once in a while and is usually followed by a long flamewar so we created a maillist specially for this: "

Curiously, the purported mailing list debian-bsd does not show up on the debian list archives, though it does appear on the list subscription page.

8. Local Version Numbers

24 Jan 2001 - 25 Jan 2001 (7 posts) Subject: "Modify a package"

Summary By Steve Robbins

People: Bao HaBen CollinsAubin Paul

Bao Ha wondered how to prevent updates from overwriting a locally-modified package.

I would like to modify a standard Debian package.

I have been using dpkg-buildpackage -b -uc to rebuild it after patching. Unfortunately, it looks just like the same as the standard package and is overwritten everytime I do update.

I have been using "=" in dselect to hold it. But is there an easier way to do it?

Putting the package on hold is certainly a valid option. The other way to achieve this is to edit version number in the debian/changelog file before building the modified package. There are several strategies to modifying the version number, each with its own advantages.

The first versioning strategy, from Ben Collins, is to just " add a 1: in front of it (e.g 1:1.0.2-1). If there is already number-colon (or epoch as it is called), then increase the number by one (e.g. 1: to 2:). " This modification will prevent the package from ever being upgraded.

Jaldhar H. Vyas, on the other hand, suggested just modifying the debian version by .1, i.e. change 1.0-1 to 1.0-1.1. With this method, in contrast to modifying the epoch, the package will be upgraded when the version changes to -2.

Finally, from Aubin Paul came the suggestion to " edit the changelog, and set the debian version to customX i.e. My custom package of qt based on 2.2.3-1 is set to 2.2.3-custom1 This way, you can easily do a dpkg -l | grep custom and see what custom packs you have, and apt will never overwrite them unless a newer upstream version is released. "

9. 2.4 Kernels In Potato

25 Jan 2001 - 26 Jan 2001 (6 posts) Archive Link: "Re: Compiling kernel 2.4.0"

Summary By Zack Brown

People: Wichert AkkermanMichael Stone

In the course of discussion, Wichert Akkerman pronounced:

I'll repeat this for the last time:

I will *not* upload a new modutils for potato to support 2.4.* kernels. The recent modutils releases don't support 2.0 kernels anymore, and a fair number of people using potato are still running those.

For the interested, there are both kernel and other packages (including util-linux, modutils and devfsd) for 2.4.0 available at that people can use if they want. Be warned that those packages are not officialy supported either by Debian or by VA, but I'll try and fix any possible bugs that people find.

Michael Stone remarked, "I assume you're going to have a check that prevents installation on a 2.0 system anyway, or people are going to get burned when they upgrade to woody." And Wichert replied, "I was always planning on doing that eventually but never got around to it. Ok, just added some code to the modutils preinst that will abort iff you are upgrading from an older modutils and you are running a pre-2.2.0 kernel that has loadable kernel module support enabled."







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.