Re: [PATCH] isar: Clean mount point on bitbake exit

[Henning Schild <henning.schild@siemens.com>]

Am Fri, 9 Feb 2018 14:19:26 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 2018-02-09 14:14, Henning Schild wrote:
> > Am Fri, 9 Feb 2018 13:41:23 +0100
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >   
> >> On 2018-02-09 13:40, Henning Schild wrote:  
> >>> Am Fri, 9 Feb 2018 13:35:15 +0100
> >>> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >>>     
> >>>> On 2018-02-09 13:33, [ext] Henning Schild wrote:    
> >>>>> Hi,
> >>>>>
> >>>>> this patch is causing problems when building in a docker
> >>>>> container, because sysfs can only be mounted ro. (Subject:
> >>>>> current next bash in buildchroot problem)
> >>>>> Now we could discuss whether we should relax the security of our
> >>>>> containers even more, or whether Isar should care about that
> >>>>> use-case.
> >>>>>
> >>>>> But this patch actually does several things at a time, it
> >>>>> changes the way we mount and adds three new mounts. I would
> >>>>> suggest to split it up so we can discuss the issues with dev
> >>>>> and sys while already merging the rest.      
> >>>>
> >>>> I think (didn't check if there was an update of next this
> >>>> morning) it works for me - in Docker. How are you starting the
> >>>> container?    
> >>>
> >>> docker run -e USER_ID=$(id -u) --rm -t -i --cap-add=SYS_ADMIN
> >>> --cap-add=MKNOD --device $(/sbin/losetup -f) -e ... proxy
> >>> stuff ... 
> >>
> >> Try adding --privileged - that's needed for binfmt anyway.  
> > 
> > Mhh i could, But. I am doing an amd64 build on an amd64 host, so i
> > do not use binfmt. And i did build arm images with binfmt and
> > without privileged before.  
> 
> That was working by chance, because you had the right settings already
> applied on the host system (binfmt is not container-ready, is not
> working per-namespace).

Ok, but if i did not care about arm i would be ok without
privileged ... whatever that means in detail.

> > So i would like to understand what has changed before dropping all
> > defense-lines in docker ... that where ok before.  
> 
> The answer to isolation remains "us a VM" for now (can also be "use
> the container insider a VM"). Docker itself is no sufficient isolation
> technology for us at this point.

True from a theoretical point of view, in practice we all use that on
our productive machines directly. I do not care about the 101st sudo in
that container, as long as i do not have to disable all security around
that.

I have already lost the "hostname" of my laptop a few times, i do not
want to see that happen to the rootfs ...

Henning

> Jan