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

[Jan-Marek Glogowski]

Am 06.02.2015 um 00:40 schrieb 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.

This sounds like a much more general approach, then my simple
"personality"-wrapper.

All the setup scripts already run as root (for mount / chroot, etc.), so
my "impersonator" is more or less like setarch - it's just more simple
and understands the schroot personality option. From my POV this doesn't
have any security implications. It's just useable from setup scripts,
which aren't changeable by users.
And even if we would expand it to a personality+chroot wrapper, it
wouldn't work, as non-root can't call chroot. What am I missing?

Thanks

Jan-Marek