http://lists.katacontainers.io/pipermail/kata-dev/2019-September/001034.html

I didn't receive this email :p
> Akihiro, is it possible for docker daemon to have a new configure option 
> instead? Something like:
>   "runtimes": {
>     "kata": {
>       "path": "kata-runtime",
>       "privileged_without_host_devices": true
>     }
>   }
>
> Then the behavior aligns well with [3]. And admins can just add it when 
> configuring docker to use kata-runtime. Then users don't need to change 
> their docker commandline options. Since the option is useful to all 
> docker+kata users, it makes sense to put it in the daemon config.
Yes, this should be possible, and actually this is very similar to what I initially proposed (reuse runtimeArgs rather than introducing a new field): https://github.com/kata-containers/runtime/issues/1568#issuecomment-516284477



2019年9月20日(金) 19:57 Akihiro Suda <suda.kyoto@gmail.com>:
The current gVisor seems always isolating devices even with --privileged, but I agree future version of gVisor may benefit from privileged-without-host-devices option.

I'll keep my Moby PR open.

2019年9月19日(木) 1:12 Fox, Kevin M <Kevin.Fox@pnnl.gov>:
Please don't take this the wrong way, as I like/use Kata. There are other isolated runtimes besides Kata though. gVisor comes to mind. I have heard of at least one other a while back not from the Kata linage. Does this dev separation work with them too? That may make it more palatable to be accepted.

Thanks,
Kevin
________________________________________
From: Akihiro Suda [akihiro.suda.cz@hco.ntt.co.jp]
Sent: Tuesday, September 17, 2019 6:35 PM
To: eric.ernst@intel.com; 'Peng Tao'
Cc: suda.kyoto@gmail.com; 'kata-dev'
Subject: Re: [kata-dev] moby PRs for running DinD with kata

Hi Tao and Eric,
Cc: my gmail


> I agree with the sentiment that privileged shouldn't be used unless
> actually necessary, which Akihirio showed isn't the case.
> FWICS, [2] doesn't work with runc, and is Kata specific?

[2] doesn't work with runc and is mostly specific to Kata.
Anyway [1] also seems specific to Kata, and doesn't seem to have any valid usecase with runc.

Regards,
Akihiro Suda

-----Original Message-----
From: eric.ernst@intel.com [mailto:eric.ernst@intel.com]
Sent: Wednesday, September 18, 2019 1:09 AM
To: Peng Tao
Cc: kata-dev; Akihiro Suda; Xu Wang
Subject: Re: moby PRs for running DinD with kata

Hey Tao,

On Tue, Sep 17, 2019 at 11:42:20PM +0800, Peng Tao wrote:
> Hi Kata developers/maintainers/AC members,
>
> Since I cannot attend the AC meeting today, I want to bring to your
> attention about two mody PRs([1] and [2]).

FWIW, I like using the ML for these kinds of discussions, anyway, since
it allows for more folks to chime in, and some digestion of the issue as
well.  Thanks for putting this on ML!

>
> Akihiro Suda developed both of them as fixes for running DinD with
> kata (aka, docker in kata). [1] is to provide a new docker security
> option --privileged-without-host-devices, similar to the fix we had
> with containerd [1]. And [2] is to simply fix the DinD entrypoint.sh
> to remount sysfs in rw mode, and use a bunch of specific options to
> tell docker to give proper permissions to DinD container.

Thanks Akihiro.

>
> While [2] is good enough to fix DinD with kata, I'm afraid there might
> be other container images out there that require similar tweaks to
> work.


I agree with the sentiment that privileged shouldn't be used unless
actually necessary, which Akihirio showed isn't the case.
FWICS, [2] doesn't work with runc, and is Kata specific?

This is probably fine for users who "know what they are doing," and
are running just in Kata? Maybe there should be a DiK or DinK image?

> So I'd like to ask for your opinions on this. Do you think [2]
> is good enough or is it better to persuade moby maintainers to go with
> [1] instead?
>

I'm glad this is fixed already in containderd (and on its way for
cri-o). I think adding a new flag would be helpful for us, but I
understand this may not be acceptable from a moby maintainer pov.
Changing the behavior of existing is too difficult for end-users, and
i'm not sure an equivalent of [3] is feasilbe either.

What do others think?

-Eric



> Cheers,
> Tao
>
> - [1] https://protect2.fireeye.com/url?k=82cd4273-de787dca-82cd6866-0cc47adc5fce-b70c583d0228b90b&q=1&u=https%3A%2F%2Fgithub.com%2Fmoby%2Fmoby%2Fpull%2F39702
> - [2] https://protect2.fireeye.com/url?k=44cf4bd5-187a746c-44cf61c0-0cc47adc5fce-d0e67658ad4ffff0&q=1&u=https%3A%2F%2Fgithub.com%2Fdocker-library%2Fdocker%2Fpull%2F191
> - [3] https://protect2.fireeye.com/url?k=bda7b490-e1128b29-bda79e85-0cc47adc5fce-3601f0663a93c4fe&q=1&u=https%3A%2F%2Fgithub.com%2Fcontainerd%2Fcri%2Fpull%2F1225
>
> --
> Into something rich and strange.



_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
https://protect2.fireeye.com/url?k=b10dcffa-edb8f043-b10de5ef-0cc47adc5fce-51d79a4c6c880768&q=1&u=http%3A%2F%2Flists.katacontainers.io%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkata-dev