[buildd-tools-devel] [RfC] Honor chroot personality in setup service script

[Roger Leigh]

On Thu, Feb 05, 2015 at 06:52:54PM +0100, Jan-Marek Glogowski wrote:
> Am 05.02.2015 um 18:31 schrieb Lennart Sorensen:
> > On Thu, Feb 05, 2015 at 04:46:45PM +0100, Jan-Marek Glogowski wrote:
> >> All the setup.d scripts run "outside" of the chroot without the schroots
> >> personality set (for mounts, nss copy etc.). The personality is just set
> >> before executing the final chroot command - be it /bin/bash or whatever
> >> you specify.
> >>
> >> Calling "linux32 schroot" is not really a workaround. There is a reason
> >> to specify the personality inside the config file, so people don't have
> >> to remember it.
> >>
> >> Probably all setup schripts should run with the correct personality when
> >> calling a command inside the chroot, so we should actually wrap the
> >> system chroot command?
> >>
> >>> personality=linux32 in the schroot config should do that for you.
> >>>
> >>> Certainly that works for me, and nothing has ever thought it was on a
> >>> 64bit system inside the chroot with that setting.

The two should be functionally identical (both call personality(2) to
set the kernel personality), at least when running the command in
the chroot.  For the setup scripts, it's true that until this mail I
hadn't really considered the issue of service startup interacting
with personalities and execdomains.

> >> This just works for the final command inside the chroot, not the setup
> >> scripts.
> > 
> > So what does your setup script do that would break?  I would have hoped
> > that running icecc would be the final command to be run in the chroot.
> > 
> > But interesting that there are cases where the setup even needs to know.
> > 
> 
> Seems I'm not clear enought about what's happening :-)
> I don't have any own setup script.
> 
> I have a build / development system (Debian Wheezy), which is running
> icecc. It's 64bit. The build schroot is an Ubuntu Precise schroot, 32bit.
> 
> The config for the schroot contains the line "setup.services=iceccd", so
> an iceccd instance is started per schroot session. The schroots iceccd
> runs without remote connect, so just distributes jobs.
> 
> So the user hacks on LibreOffice in the schroot and compiles using all
> free icecc resources on several machines.
> 
> But without the patch / personality-helper, the schroot sessions iceccd
> is started in the host system context, so it thinks, it's running on a
> 64bit system and generates 64bit object files, which obviuosly fails to
> link, when the build system expects 32bit object files.
> 
> Hope this is more understandable with the context.

This explains things much more clearly, thanks.

I think you're correct that there needs to be some sort of wrapper,
e.g. schroot-exec like schroot-mount which can run commands in a
chroot.  I'll have to think over the security and permissions side
of things--we don't want an end user to be able to run stuff in
arbitrary chroots.  We might need to factor out the execution steps
inside schroot::session since this does all the setuid/personality
stuff, but we'll need to have a way to pass all the security and
configuration parameters in the setup script environment.

Kind regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800