Am 10.11.2017 um 20:42 schrieb Alexander Smirnov:
> Hi,
>
> On 11/10/2017 09:59 PM, Jan Kiszka wrote:
>> On 2017-11-09 10:57, Alexander Smirnov wrote:
>>> Hello everybody,
>>>
>>> I've tried to completely switch Isar to PRoot, so here are the problems
>>> I've faced with:
>>>
>>> 1. PRoot doesn't work with UID/GID, all the files in PRoot are owned by
>>> root. The command 'chown' doesn't have any effect.
>>>
>>> 2. Some system commands are failed in PRoot: passwd, chpasswd. I see
>>> message: System error, no other clues (but for Wheezy these commands 
>>> work).
>>>
>>> 3. mkfs.ext4 doesn't work under proot, lots of files are dropped in
>>> resulting image.
>>>
>>> So, summary:
>>> ============
>>>
>>> 1. PRoot could be an intermediate option for:
>>>   + Buildchroot creation.
>>>   + Packages building.
>>>   - Drawback: works slowly.
>>
>> Aren't issues 1 and 2 from above affecting these use cases as well?
>>
>
> For now I don't have any facts about problems with buildchroot, but my 
> test includes only 'hello' and 'example-raw' applications.
>
>  - Regarding UID/GID, what I've seen for now, these manipulations are 
> done in postinst scripts.
>  - Passwd/chpasswd commands are also used in postinst scripts (for 
> example initrd package), there is no need to have passwords in 
> buildchroot because we are working under root.
>
> So, roughly speaking, buildchroot is only needed to compile and pack 
> the binary package, what doesn't require multi-UID/GID and passwords 
> support.
>
> But for sure, it needs to build much more real packages to have more 
> precise statistics. :-(
>
> So I've created dedicated branch 'asmirnov/proot' for possible 
> experiments in future.
>
>>>
>>> 2. For image generation the other tool should be considered.
>>>
>>
>> What is plan B now? Plan C remains falling back to VM builds, I suppose.
>
> So there are 2 options remain for evaluation:
>  - fakeroot
>  - pseudo
>
> I'd like to evaluate these tools for the features, that are uncovered 
> now:
>
>  - rootfs with UID/GID support: in general PRoot is able to generate 
> multistrap rootfs with just *upacked* Debian packages, all the 
> problems occur when I try to run 'dpkg-configure -a' inside this rootfs.
>
>  - ext2fs image generation (AFAIK this already is supported by Yocto, 
> but unfortunately I don't know too much, I need to take a look first).
>
> From this evaluation I'd like to get two points:
>
> 1. Could we somehow implement quick PoC to drop 'sudo' for Isar. This 
> PoC could be based on several tools in parallel.
>
> 2. If the item above is possible - then choose one dedicated tool and 
> try to adapt it for our needs.
>
> Alex
>
Ok bad news, but I faced the same problems, when trying to use one of 
these tools. Each tool has own drawbacks and benefits, but no tool 
combines multiple drawbacks to fit our needs.

I don't want to bother you, but why can't we try to focus on running 
builds with docker support?

Create a wrapper around "bitbake" which first performs a docker 
container setup and then runs the bitbake build.

Using such wrapper can make the docker thing almost transparent.


I know there are some problems getting a docker container secure, but 
maybe a focus on trying to get a docker based isar build secure, is 
easier to reach than the our current approaches?

It is possible to drop some capabilities for docker in order to make it 
more secure (e.g. don't allow to create dev files).

A mount command is also not required since, new versions of mkfs have 
the "-d" option included (specifiy a directory, which copied into the 
filesystem image). So no sys_admin capabilities would be needed.

It is also possible to customize other things within the container to 
make it more secure:

- Add only required commands to sudoers file.

- Modify permissions to files/directories.

- Think about which commands within isar really need root privileges, 
and drop those.


I think, if somebody seriously wants to exploit the container, he will 
also reach that with a non-root based build.

The attachment contains a (very basic and rudimentary) approach of 
running docker based isar builds.


Benedikt