fakechroot

fakechroot

[Quirin Gylstorff]

Hi,

did somebody tried to use fakechroot for bootstrapping and chroot?

Quirin

Re: fakechroot

[Baurzhan Ismagulov]

Hello Quirin,

On Fri, Sep 13, 2019 at 10:00:51AM +0200, Quirin Gylstorff wrote:
> did somebody tried to use fakechroot for bootstrapping and chroot?

Alex explored the available sudo alternatives, but not fakechroot. How would
you like to use it?

With kind regards,
Baurzhan.

Re: fakechroot

[Baurzhan Ismagulov]

On Fri, Sep 13, 2019 at 11:08:21AM +0200, Quirin Gylstorff wrote:
> This was only an initial test but with fakechroot and fakeroot it should be
> possible to have a non-priviledged debootstrap and chroot process.
> 
> - Initial Creating with debootstrap did work. e.g.:
>   fakechroot fakeroot debootstrap buster amd64
> - what also work was using chroot to enter the create rootfs.
>   fakechroot chroot amd64

Thanks for sharing. That could be a welcome change.

1. How does fakechroot fakeroot perform privileged operations like chown,
   mknod, accessing other's files, mounting, etc.?

   We need that information to be consistent across multiple commands in
   multiple recipes (bootstrap, customize, install stuff, deploy, etc.).
   Wrapping one command is probably possible with any tool -- but currently I
   don't see how they could do what we need.

   Regarding keeping the information across multiple commands, Yocto's pseudo
   should allegedly be able to do that (not sure whether it keeps the state in
   a daemon or a file). Evaluating that was our next step (very low prio ATM)
   -- maybe that could be interesting for you as well.

2. fakechroot fakeroot is reported to work with foreign-arch chroots. Have you
   tried that?

With kind regards,
Baurzhan.

Re: fakechroot

[Jan Kiszka]

On 13.09.19 11:33, Baurzhan Ismagulov wrote:
> On Fri, Sep 13, 2019 at 11:08:21AM +0200, Quirin Gylstorff wrote:
>> This was only an initial test but with fakechroot and fakeroot it should be
>> possible to have a non-priviledged debootstrap and chroot process.
>>
>> - Initial Creating with debootstrap did work. e.g.:
>>    fakechroot fakeroot debootstrap buster amd64
>> - what also work was using chroot to enter the create rootfs.
>>    fakechroot chroot amd64
> 
> Thanks for sharing. That could be a welcome change.
> 
> 1. How does fakechroot fakeroot perform privileged operations like chown,
>     mknod, accessing other's files, mounting, etc.?
> 
>     We need that information to be consistent across multiple commands in
>     multiple recipes (bootstrap, customize, install stuff, deploy, etc.).
>     Wrapping one command is probably possible with any tool -- but currently I
>     don't see how they could do what we need.
> 
>     Regarding keeping the information across multiple commands, Yocto's pseudo
>     should allegedly be able to do that (not sure whether it keeps the state in
>     a daemon or a file). Evaluating that was our next step (very low prio ATM)
>     -- maybe that could be interesting for you as well.
> 
> 2. fakechroot fakeroot is reported to work with foreign-arch chroots. Have you
>     tried that?
> 

Note that we can't use fakeroot for most package builds because Debian use it as 
well, and nesting is not supported.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: fakechroot

[Baurzhan Ismagulov]

On Fri, Sep 13, 2019 at 11:41:52AM +0200, Jan Kiszka wrote:
> Note that we can't use fakeroot for most package builds because Debian use
> it as well, and nesting is not supported.

If Debian supports building packages as root, one could dpkg-buildpackage
without fakeroot.

With kind regards,
Baurzhan.

Re: fakechroot

[Henning Schild]

Am Fri, 13 Sep 2019 11:41:52 +0200
schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:

> On 13.09.19 11:33, Baurzhan Ismagulov wrote:
> > On Fri, Sep 13, 2019 at 11:08:21AM +0200, Quirin Gylstorff wrote:  
> >> This was only an initial test but with fakechroot and fakeroot it
> >> should be possible to have a non-priviledged debootstrap and
> >> chroot process.
> >>
> >> - Initial Creating with debootstrap did work. e.g.:
> >>    fakechroot fakeroot debootstrap buster amd64
> >> - what also work was using chroot to enter the create rootfs.
> >>    fakechroot chroot amd64  
> > 
> > Thanks for sharing. That could be a welcome change.
> > 
> > 1. How does fakechroot fakeroot perform privileged operations like
> > chown, mknod, accessing other's files, mounting, etc.?
> > 
> >     We need that information to be consistent across multiple
> > commands in multiple recipes (bootstrap, customize, install stuff,
> > deploy, etc.). Wrapping one command is probably possible with any
> > tool -- but currently I don't see how they could do what we need.
> > 
> >     Regarding keeping the information across multiple commands,
> > Yocto's pseudo should allegedly be able to do that (not sure
> > whether it keeps the state in a daemon or a file). Evaluating that
> > was our next step (very low prio ATM) -- maybe that could be
> > interesting for you as well.
> > 
> > 2. fakechroot fakeroot is reported to work with foreign-arch
> > chroots. Have you tried that?
> >   
> 
> Note that we can't use fakeroot for most package builds because
> Debian use it as well, and nesting is not supported.

Are you sure that is an issue, did you try? Most fakeroot aware tools
will detect that they are already running in fakeroot and will not try
to nest.

Henning

> Jan
> 

Re: fakechroot

[Jan Kiszka]

On 17.09.19 11:14, Henning Schild wrote:
> Am Fri, 13 Sep 2019 11:41:52 +0200
> schrieb "[ext] Jan Kiszka" <jan.kiszka@siemens.com>:
> 
>> On 13.09.19 11:33, Baurzhan Ismagulov wrote:
>>> On Fri, Sep 13, 2019 at 11:08:21AM +0200, Quirin Gylstorff wrote:
>>>> This was only an initial test but with fakechroot and fakeroot it
>>>> should be possible to have a non-priviledged debootstrap and
>>>> chroot process.
>>>>
>>>> - Initial Creating with debootstrap did work. e.g.:
>>>>     fakechroot fakeroot debootstrap buster amd64
>>>> - what also work was using chroot to enter the create rootfs.
>>>>     fakechroot chroot amd64
>>>
>>> Thanks for sharing. That could be a welcome change.
>>>
>>> 1. How does fakechroot fakeroot perform privileged operations like
>>> chown, mknod, accessing other's files, mounting, etc.?
>>>
>>>      We need that information to be consistent across multiple
>>> commands in multiple recipes (bootstrap, customize, install stuff,
>>> deploy, etc.). Wrapping one command is probably possible with any
>>> tool -- but currently I don't see how they could do what we need.
>>>
>>>      Regarding keeping the information across multiple commands,
>>> Yocto's pseudo should allegedly be able to do that (not sure
>>> whether it keeps the state in a daemon or a file). Evaluating that
>>> was our next step (very low prio ATM) -- maybe that could be
>>> interesting for you as well.
>>>
>>> 2. fakechroot fakeroot is reported to work with foreign-arch
>>> chroots. Have you tried that?
>>>    
>>
>> Note that we can't use fakeroot for most package builds because
>> Debian use it as well, and nesting is not supported.
> 
> Are you sure that is an issue, did you try? Most fakeroot aware tools
> will detect that they are already running in fakeroot and will not try
> to nest.

I've ran into problems when nesting inside the build. Maybe the outer fakeroot 
call would detect and avoid that, but I would not bet on that.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: fakechroot

[Quirin Gylstorff]

On 9/13/19 11:33 AM, Baurzhan Ismagulov wrote:
> On Fri, Sep 13, 2019 at 11:08:21AM +0200, Quirin Gylstorff wrote:
>> This was only an initial test but with fakechroot and fakeroot it should be
>> possible to have a non-priviledged debootstrap and chroot process.
>>
>> - Initial Creating with debootstrap did work. e.g.:
>>    fakechroot fakeroot debootstrap buster amd64
>> - what also work was using chroot to enter the create rootfs.
>>    fakechroot chroot amd64
> 
> Thanks for sharing. That could be a welcome change.
> 
> 1. How does fakechroot fakeroot perform privileged operations like chown,
>     mknod, accessing other's files, mounting, etc.?
> 
>     We need that information to be consistent across multiple commands in
>     multiple recipes (bootstrap, customize, install stuff, deploy, etc.).
>     Wrapping one command is probably possible with any tool -- but currently I
>     don't see how they could do what we need.
> 
>     Regarding keeping the information across multiple commands, Yocto's pseudo
>     should allegedly be able to do that (not sure whether it keeps the state in
>     a daemon or a file). Evaluating that was our next step (very low prio ATM)
>     -- maybe that could be interesting for you as well.
> 

fakechroot, fakeroot and pseudo are all using a similar mechanism by 
modifying the LD_PRELOAD_PATH with there own Libraries and abstracting 
the necessary systemcalls. pseudo uses a sqlite Database to get a 
persistent view on the topic.

> 2. fakechroot fakeroot is reported to work with foreign-arch chroots. Have you
>     tried that?

I will test it.
> 
> With kind regards,
> Baurzhan.
> 

Re: fakechroot

[Baurzhan Ismagulov]

On Fri, Sep 13, 2019 at 12:57:45PM +0200, Quirin Gylstorff wrote:
> fakechroot, fakeroot and pseudo are all using a similar mechanism by
> modifying the LD_PRELOAD_PATH with there own Libraries and abstracting the
> necessary systemcalls. pseudo uses a sqlite Database to get a persistent
> view on the topic.

Thanks, the persistent view was my actual question. I think we should be
looking at pseudo, since the tools without persistency aren't going to work for
our use case. Or do you see a possibility for fakechroot fakeroot?

With kind regards,
Baurzhan.

Re: fakechroot

[Quirin Gylstorff]

On 9/13/19 2:11 PM, Baurzhan Ismagulov wrote:
> On Fri, Sep 13, 2019 at 12:57:45PM +0200, Quirin Gylstorff wrote:
>> fakechroot, fakeroot and pseudo are all using a similar mechanism by
>> modifying the LD_PRELOAD_PATH with there own Libraries and abstracting the
>> necessary systemcalls. pseudo uses a sqlite Database to get a persistent
>> view on the topic.


> 
> Thanks, the persistent view was my actual question. I think we should be
> looking at pseudo, since the tools without persistency aren't going to work for
> our use case. Or do you see a possibility for fakechroot fakeroot?
>


If using fakeroot and fakechroot, debootstrap knows it is running in a 
fakeroot and adapts itself to this environment. From the previous test 
with pseudo it does not do that for pseudo[1].

I did not test of pseudo runs with --variant=fakeroot.

[1] 
https://groups.google.com/forum/#!msg/isar-users/WV0N4X2ZZMo/4EQI3c1wBQAJ

> With kind regards,
> Baurzhan.
> 

Kind regards
Quirin

Re: fakechroot

[Henning Schild]

Am Mon, 16 Sep 2019 10:38:44 +0200
schrieb "[ext] Quirin Gylstorff" <quirin.gylstorff@siemens.com>:

> On 9/13/19 2:11 PM, Baurzhan Ismagulov wrote:
> > On Fri, Sep 13, 2019 at 12:57:45PM +0200, Quirin Gylstorff wrote:  
> >> fakechroot, fakeroot and pseudo are all using a similar mechanism
> >> by modifying the LD_PRELOAD_PATH with there own Libraries and
> >> abstracting the necessary systemcalls. pseudo uses a sqlite
> >> Database to get a persistent view on the topic.  
> 
> 
> > 
> > Thanks, the persistent view was my actual question. I think we
> > should be looking at pseudo, since the tools without persistency
> > aren't going to work for our use case. Or do you see a possibility
> > for fakechroot fakeroot? 
> 
> 
> If using fakeroot and fakechroot, debootstrap knows it is running in
> a fakeroot and adapts itself to this environment. From the previous
> test with pseudo it does not do that for pseudo[1].
> 
> I did not test of pseudo runs with --variant=fakeroot.
> 
> [1] 
> https://groups.google.com/forum/#!msg/isar-users/WV0N4X2ZZMo/4EQI3c1wBQAJ

Debootstrap is just one "problem", and i think we had that running
without a privileged container or "root".

A full build involves potentially setting binfmt and running wic, which
brings in a lot of tools (filesystems, partitions, bootloaders). OE
knows them as "wtools_sysroot" and builds them with dynamic linking
(for the LD_PRELOAD trick).
But we use the ones from our target distro in buildchroot, and guess
what, they are essential system tools that are statically linked. So no
LD-messing with them ...

Lowering the privileges for some steps (like debootstrap) might be a
good idea, but i still do not see how to do a full Isar build without
root.

Henning

> > With kind regards,
> > Baurzhan.
> >   
> 
> Kind regards
> Quirin
>