Package: live-build Version: 4.0.3-1 The Live Build manual describes how to prepare a system in the chroot stage.
I do it. On my live system (a firewall), I find destroyed settings in /etc/hosts, /etc/network/interfaces, /etc/resolv.conf and probably several others. Further, a user not existing in the chroot, "user" is created with a world-known password "live". This user can sudo. (and via a little bit of TCP, the whole world can sudo on my box...) I had to spend many hours to dig out, what happened and how to work around all this surprising magic. The reporter of case #787617 was surprised, too. The architectural flaw, that I see in all these symptoms, is, that live-build violates the principle of least surprise. It is a great tool to automate the building of live images. And without all the magic, it could be a great tool to do this generically for arbitrary live images based on Debian and Ubuntu. The problem is, that this magic happens by default. It is clear, that there has to be a separation between build time customisation (which determines the properties of all produced live images) and run time customisation (determining the properties of the particular running instance). BUT: if I did not do any particular runtime configuration, I expect, that the system behaves as defined at build time -- and if I do a particular chroot-time customisation, that it survives chroot time (/etc/hosts is destroyed in a later stage of lb_build). This way, a tool, promising to be simple and used for a simple use case, becomes complicated and unforeseeably expensive. I would propose to switch default (no customisation) behaviour to the simplest possible. Eg., if I don't define a live user, there will be none, if I don't switch something on, which alters my /etc/network/interfaces, it shouldn't, ... The various customisation "switches" shall have well-defined and -documented behaviour. Otherwise, the risk is too high, that I'm building a system full of security flaws. Carpe diem
