Re: PRoot: Drop sudo around buildchroot

[Ben Brenson <benbrenson89@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]

2017-10-25 17:29 GMT+02:00 Alexander Smirnov <asmirnov@ilbers.de>:

>
>
> On 10/25/2017 05:58 PM, 'Benedikt Niedermayr' via isar-users wrote:
>
>> Am 25.10.2017 um 11:48 schrieb Alexander Smirnov:
>>
>>>
>>>
>>> On 10/24/2017 11:22 PM, Jan Kiszka wrote:
>>>
>>>> On 2017-10-24 21:34, Alexander Smirnov wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I've successfully dropped 'sudo' around buildchroot operations:
>>>>>
>>>>>   - Create buildchroot
>>>>>   - Build dpkg-base package (hello)
>>>>>   - Build dpkg-raw package (example-raw)
>>>>>
>>>>> The patch is quite small, proot works out-of-the box. I've tested the
>>>>> following configurations:
>>>>>
>>>>>   - multiconfig:qemuarm-wheezy:isar-image-base
>>>>>   - multiconfig:qemuarm-jessie:isar-image-base
>>>>>   - multiconfig:qemuarm-stretch:isar-image-base
>>>>>   - multiconfig:qemui386-jessie:isar-image-base
>>>>>   - multiconfig:qemui386-stretch:isar-image-base
>>>>>   - multiconfig:qemuamd64-jessie:isar-image-base
>>>>>   - multiconfig:qemuamd64-stretch:isar-image-base
>>>>>
>>>>> So proot is really good tool :-)
>>>>>
>>>>> If you'd like to reproduce the test, please try my branch:
>>>>> asmirnov/devel
>>>>>
>>>>> NOTE: do not forget to install proot: apt-get install proot
>>>>>
>>>>> Build command:
>>>>> $ bitbake multiconfig:qemuarm-wheezy:isar-image-base
>>>>> multiconfig:qemuarm-jessie:isar-image-base
>>>>> multiconfig:qemuarm-stretch:isar-image-base
>>>>> multiconfig:qemui386-jessie:isar-image-base
>>>>> multiconfig:qemui386-stretch:isar-image-base
>>>>> multiconfig:qemuamd64-jessie:isar-image-base
>>>>> multiconfig:qemuamd64-stretch:isar-image-base
>>>>>
>>>>>
>>>> Great news! Hope this passes all tests and then makes it into master
>>>> soon!
>>>>
>>>>
>>> I've tested QEMU machines for images listed above, no difference
>>> observed in comparison with original 'sudo' approach. But anyway, it would
>>> be nice if somebody else will test this, especially in customer project
>>> environment.
>>>
>>> May there be a problem when all files belonging to the build user and
>> not to root?
>>
>
> That's exactly the topic why I started proot with buildchroot and why I'm
> asking about various test results (did you try? :-)).
>
> In the VM that I've built with proot patch I see the following:
>
> root@isar:~# ls -l /usr/bin/ | grep hello
> -rwxr-xr-x 1 root root   18068 Oct 24 18:52 hello
> root@isar:~#
>
> So the file from hello package (which is built using proot) has root
> ownership.
>
>
> In theory the problems could occur during generation of target filesystem,
> will see. But anyway, Yocto will do this without sudo, so probably here
> also this could be done.
>
> Alex
>


What I was trying, was to run a proot based build, from my current Isar
fork. Then I had the problem with file permissions (files belonging to
build user instead to root).


The Problem can be located at the point when installing the deb packages to
the rootfs (do_deploy() with fake root permissions). After exiting the
proot all files there have the permissions
of my build user. And after that wic will generate the rootfilesystem image
with those permissions.

So when the deb package is generated, all (faked) root permissions are
stored but get lost in case of installing that package as normal user, or
after exiting the proot.

Yocto does somethin similiar but better:
It starts pseudo, which in turn stores all (faked) file permissions and
later runs mkfs.ext3 with the -d option, within pseudo environment.
The -d <rootfs_dir> option makes mkfs to copy all files directly into the
created filesystem in a single step.
When mounting that filesystem image (which is only possible as root) I can
see the correct file permissions.

I think this similar to creating tar archives. When creating files as root
within the fakeroot and compress them as fakeroot user, all root
permissions where also stored within the archive.
When extracting that archive as root, all files have root permissions.
When extracting that archive as user, all files have user permissions.

So the -d option is similiar to compressing files into an archive, I think.

I have not tested that behavior with proot, yet.

Reagards,
Benedikt

[-- Attachment #2: Type: text/html, Size: 5567 bytes --]