Greetings, Repin,

I am unclear how this answers my current questions.  System containers are 
marketed as being very close to a faster VM, as such, since I do have control 
over the OS I am trying to run on top, I would need more details as to why and 
which areas would cause the technical issues to achieve such thing.  The fact 
that the System container shares the kernel here is totally what I am looking 
for, there is also no other application running on the host except that 
container and snapd itself which should not be a problem as it removes any race 
where one app may changes kernel-related configuration from under the OS within 
the container.

I do understand that this is unconventional and doesn't appear to fall under 
the supported scenarios.  Yet, so far the issue I am facing does not appear 
related to my final goal.

  *   Can't execute any command within container -> permission denied (files 
are all uid/gid 0) this is a busybox type of OS on same CPU architecture (both 
armhf where host is arm64, yet metadata provided indicate that container should 
be armhf)
  *   Still seeing issue trying to write /proc and even though I say mount rw I 
get read-only errors
  *   Fail to load the kernel module even though I have clear the cap.drop as 
to keep cap_sys_modules.

I am currently doing those evaluations under Ubuntu Core 18.04 with lxd 
installed as a snap.

--
Yannick Koehler
________________________________
From: lxc-users <lxc-users-boun...@lists.linuxcontainers.org> on behalf of 
Andrey Repin <anrdae...@yandex.ru>
Sent: June 15, 2020 10:49 AM
To: Yannick Koehler <lxc-users@lists.linuxcontainers.org>; All 
<lxc-users@lists.linuxcontainers.org>
Subject: Re: [lxc-users] Running unprotected system container

Greetings, Koehler!

> As indicated, the code that will run inside that container is our previous
> OS and if it does bad things, well, that means it was doing so previously so
> not a "bigger" issue than it was before.  Since if that works, we will move
> more towards snap we will then  have a better security system (AppArmor,
> SecComp, better app separation, etc) in place to remove trust for each app
> and get rid eventually of that container which purpose as indicated is to
> ease the transition and get some of the features we want from Ubuntu  Core
> in an early release, if we do get this to work.

If your intent is to run specifically **operating system**, then there's no way
around a virtual machine.

Containers is NOT the right choice for your task.


--
With best regards,
Andrey Repin
Monday, June 15, 2020 17:47:30

Sorry for my terrible english...

_______________________________________________
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Reply via email to