From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6480563028650622976 X-Received: by 10.36.173.88 with SMTP id a24mr720267itj.24.1509008224083; Thu, 26 Oct 2017 01:57:04 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.107.111.11 with SMTP id k11ls211577ioc.7.gmail; Thu, 26 Oct 2017 01:57:03 -0700 (PDT) X-Google-Smtp-Source: ABhQp+SH3xr6AWySD/7aH95ojhteg9AqxjWlNS/rxpezH3DTuYXcCjC8hjE1v5I4kdUpxYjsP2mx X-Received: by 10.107.187.5 with SMTP id l5mr10530653iof.34.1509008223832; Thu, 26 Oct 2017 01:57:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509008223; cv=none; d=google.com; s=arc-20160816; b=KpUlGKZ96jTgvWnFU+T/OuOEg9L1or/VC2cfnEcPrIOWKjnsg2gmX9MbMulvtsXZ2D U9S2b8o5R9yNonzBZw/ppagWaqj/Tn3nEM9a2GqCk9ZLipXN3m2OJ8CU8NI46CJWmBTE 50IVc7Z9EzpXRUzCnZa9NSllGH/zg7kucvx0TJ/sXCilbwxSpnRL+YXeFO8xvR7DwmIf foiosZUWjLS2Xux0Af7OoeHq8t7p30v8FuM9vt+JUKn0gM7ohVpFSlkUOfqXaTiuChKD bOpETjXoOcWah42P2xTHl3hDWiRg4a/r+lzsmKs6/zasWTB+WEmx7h1nV8OnFrgPe7q6 FcFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=oEBgO6xry9cJANz7xxIAM/85VF+6ynQ/GzB81kolm6s=; b=pezQ2bpNqx69XG69duKLaKIM3H3WsdtgL4AJp8sh+1OzrwgrHjEli2ybimus0xQpBW 2HhV14fqYHgQdjBM7pIbm16DvXoBcMeDZ44WZ4WGwfOacm3lz+UnuY4wKinJlkKxAOfD d6wCbHOXY3fVn3vH6Dp6LXJEDzQe1RYrR5KytaFYKgR1BuEKCy9Sx3fLbLW4UpZDde7m MmCsNHHZteegfvFLUrasjEJFyggVV7h8VU9nsjsMgwtvr/gQRKbumQTJB/ZaMRqZ00c7 i5UOEAcm24ZkKChGbFOUXBFp85ibdPk/aFN7fedpKKo0KRgJNFZQd8oKdV0/vdomlpqp wdXQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=VKyCP026; spf=pass (google.com: domain of benbrenson89@googlemail.com designates 2607:f8b0:4001:c0b::22d as permitted sender) smtp.mailfrom=benbrenson89@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com. [2607:f8b0:4001:c0b::22d]) by gmr-mx.google.com with ESMTPS id n1si363891ioc.4.2017.10.26.01.57.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 01:57:03 -0700 (PDT) Received-SPF: pass (google.com: domain of benbrenson89@googlemail.com designates 2607:f8b0:4001:c0b::22d as permitted sender) client-ip=2607:f8b0:4001:c0b::22d; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=VKyCP026; spf=pass (google.com: domain of benbrenson89@googlemail.com designates 2607:f8b0:4001:c0b::22d as permitted sender) smtp.mailfrom=benbrenson89@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: by mail-it0-x22d.google.com with SMTP id c3so4371514itc.3 for ; Thu, 26 Oct 2017 01:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oEBgO6xry9cJANz7xxIAM/85VF+6ynQ/GzB81kolm6s=; b=VKyCP026rgA1alFnHCTEfCcjaM/lN6xRpJpaAInkLfjfrEQNFiwzEYfnJSDhAwV29p H1TPieBUUS1x5Rdvvoke9rG6crH58S5GN1KvcxzgPdXc2lMCQ5g/T2bJui90ujDrsI/v aJJZj2JUbVFJ3ZemVjaZtvctoX72Yfy9/hjz4EDxMpuqYcMeFu1VAA70ovlbNJqf5t25 +/IoWrj0NR/sVzqJQKZbGypiuNLe1lgzMBF+zfZkmgJHEEnQxc1XA0ETx0PHygDMkWIG ZOHszM9NpHMi0Iqtg09k/shqFCkDq7UUF0SHj2vA2THQ/bmfCnBHXlLMPDQuPDA980di 2G1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oEBgO6xry9cJANz7xxIAM/85VF+6ynQ/GzB81kolm6s=; b=KAc2098owVwqbfbx578N+s6jlUlSWCnEvxhhKUPosVkxdoL40hCEZHWHi1h1D79w2t nGAI0vY7MGdT9Yfyyuj805a380FP3q0vZcVa9ieY1XXkQqj0h5Q0IKbfa/308n+3Zqk/ 0iSJvO1AZ+EelK4HeaIXd/ozLp5VSnudUZhlbBkM5aWZCLDldqIkelUONxLHal80s5Z1 DCQjFxCSv0caNWUYSAvgOTsgUoJEysKEWDxfr0gZNlKrahEVp9b4GmH10GmE2x+3E0zp H4J1GLTEsVaib4tKh63XHzmrd9p+sxkpww4LpaoYSEJJQvZHvw9GMgO/qAovPGtnJQaR QTEg== X-Gm-Message-State: AMCzsaVgnLoxR23KqtnmsXbfmRrbrJRNBPD4igZiLGfDEwJ+rjgBZFrf jD9jhwDXs0lZZgI5O2mzvg/4f0Muutgy5fHMGr2qvg== X-Received: by 10.36.43.193 with SMTP id h184mr1388779ita.15.1509008223420; Thu, 26 Oct 2017 01:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.155.106 with HTTP; Thu, 26 Oct 2017 01:57:02 -0700 (PDT) In-Reply-To: <267f7c90-272f-df53-99ee-f041a8407b9d@ilbers.de> References: <8e0fb678-085a-1403-3ee9-f3afef3c080a@ilbers.de> <00b0017a-62e0-1e1b-4d67-786af7702f8d@siemens.com> <14315725-092a-8d1f-0c02-98efc30e7f2e@googlemail.com> <267f7c90-272f-df53-99ee-f041a8407b9d@ilbers.de> From: Ben Brenson Date: Thu, 26 Oct 2017 10:57:02 +0200 Message-ID: Subject: Re: PRoot: Drop sudo around buildchroot To: Alexander Smirnov Cc: isar-users Content-Type: multipart/alternative; boundary="001a1146f4081ec72f055c6f5ba4" X-TUID: 14IdRR7zbi9Y --001a1146f4081ec72f055c6f5ba4 Content-Type: text/plain; charset="UTF-8" 2017-10-25 17:29 GMT+02:00 Alexander Smirnov : > > > 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 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 --001a1146f4081ec72f055c6f5ba4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017-10-25 17:29 GMT+02:00 Alexander Smirnov <asmirnov@ilbers.de&= gt;:


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:=

=C2=A0 - Create buildchroot
=C2=A0 - Build dpkg-base package (hello)
=C2=A0 - Build dpkg-raw package (example-raw)

The patch is quite small, proot works out-of-the box. I've tested the following configurations:

=C2=A0 - multiconfig:qemuarm-wheezy:isar-image-base
=C2=A0 - multiconfig:qemuarm-jessie:isar-image-base
=C2=A0 - multiconfig:qemuarm-stretch:isar-image-base
=C2=A0 - multiconfig:qemui386-jessie:isar-image-base
=C2=A0 - multiconfig:qemui386-stretch:isar-image-base
=C2=A0 - multiconfig:qemuamd64-jessie:isar-image-base
=C2=A0 - 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/dev= el

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!<= br>

I've tested QEMU machines for images listed above, no difference observ= ed in comparison with original 'sudo' approach. But anyway, it woul= d be nice if somebody else will test this, especially in customer project e= nvironment.

May there be a problem when all files belonging to the build user and not t= o 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=C2=A0 =C2=A018068 Oct 24 18:52 hello
root@isar:~#

So the file from hello package (which is built using proot) has root owners= hip.


In theory the problems could occur during generation of target filesystem, = will see. But anyway, Yocto will do this without sudo, so probably here als= o this could be done.

Alex


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


The Problem can=20 be located at the point when installing the deb packages to the rootfs=20 (do_deploy() with fake root permissions). After exiting the proot all=20 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=20 stored but get lost in case of installing that package as normal user,=20 or after exiting the proot.

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

I think this similar to creating tar archives. When creating files as=20 root within the fakeroot and compress them as fakeroot user, all root=20 permissions where also stored within the archive.=C2=A0
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 be= havior with proot, yet.

Reagards,
Benedikt



--001a1146f4081ec72f055c6f5ba4--