Open Stack

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 at 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 at hco.ntt.co.jp]
> Sent: Tuesday, September 17, 2019 6:35 PM
> To: eric.ernst at intel.com; 'Peng Tao'
> Cc: suda.kyoto at 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 at intel.com [mailto:eric.ernst at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190920/25d73b3e/attachment-0001.html>