Re: ia32-libs{-tools}, multiarch, squeeze

[Roger Leigh <rleigh@codelibre.net>]

On Sun, Jul 05, 2009 at 11:36:31PM +0200, Goswin von Brederlow wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
> 
> > As I see it, there are two major hurdles:
> >
> > 1) Initial creation of the chroot.  As above, I think a simple script
> >    to integrate with the existing tools would work just fine here.
> 
> Which must handle all possible user configurations for mail, sound,
> printing, ....

I'm not sure I agree here.  "All possible configurations" is a rather
impossible goal for any system.

The creator of any package would need to decide what to support by
default.  It can use the d-i tasks just like a normal installation
would, but the user will ultimately have the power to configure it
as they see fit.

Although I use amd64, I have yet to want to install any 32bit
software, so I'm not entirely sure what the use case is for it.  If
we're talking about specific programs such as proprietary binary-
only software and browser plugins etc., then we really only need
the specific software and its dependencies in there.  I really don't
see the need for an entire functional desktop environment inside the
chroot, for example.  Some further clarification is needed here.

> > 2) An easy way to run programs inside the chroot.  This depends upon
> >    exactly what you want to do.  Wrapper scripts or shell aliases do
> >    a good job for existing users; automatically generated desktop
> >    menu files for specific applications would also work.
> 
> Which then can't generaly send mail, play sound nicely (mix with the
> non-chroot sound), print documents, ...

These tasks just require the necessary client libraries and/or
programs to talk to the server.  In the case of the sound, the
device nodes are shared with the host system, as is SYSV and POSIX SHM.
For server AF_LOCAL sockets, we can bind mount the sockets in there
as well.

> And most unsovably: You can not start 64bit programs from inside the
> 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How
> many levels bind mounts do you want to do?

Well, from a kernel POV, you can certainly use personality(2) to
switch the execdomain back to PER_LINUX from PER_LINUX32.

You are correct that starting 64bit programs on the host from inside
the chroot is not possible.  The isolation of the filesystem from the
host is, of course, the defining feature of a chroot environment.  If
we are running specific programs inside only, is this a problem in
practice?

It's certainly possible to install schroot inside the chroot and then
chroot back into a virtual host system, but I do admit that's rather
gross!

> > While I agree that chroots do appear more technical and fiddly to
> > set up, the reality is that we now have the means to set them up
> > in a reliable and automated fashion, and this will give the user
> > a more robust environment than a monolithic library package set
> > from a security POV, as well as giving them access to the /entire/
> > archive rather than a restricted subset, making it rather more
> > useful.  While multiarch should solve this problem, chroots offer
> > rather more functionality and reliability at the present time,
> > with a (rather small) hurdle to set up initially.
> 
> Not in a way that is suitable for general desktop applications.
> 
> And hey, here is this existing way of doing all this so that none of
> these problems arise: ia32-apt-get. It also is not monolithic, nor a
> security problem and also gives access to the full archive. Initially
> it was too much of it even.

I'd rather see a working multiarch implementation in the long term.  I
agree that the chroot setup is not as ideal as multiarch, but there are
quite a lot of people using schroot in practice for this purpose.

I would be interested to know exactly why it's not suitable for
general desktop applications, and exactly what use cases you are
planning for which lead to this being the case.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.