From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Peter Dolding <oiaohm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: Roadmap for features planed for containers where and Some future features ideas.
Date: Mon, 21 Jul 2008 05:13:27 -0700 [thread overview]
Message-ID: <m1k5ffmo48.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <e7d8f83e0807210403g12b980e8jad4fa7e10d8b410e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Peter Dolding's message of "Mon, 21 Jul 2008 21:03:47 +1000")
"Peter Dolding" <oiaohm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> http://opensolaris.org/os/community/brandz/ I would like to see if
> something equal to this is on the roadmap in particular. Being able
> to run solaris and aix closed source binaries contained would be
> useful.
There have been projects to do this at various times on linux. Having
a namespace dedicated to a certain kind of application is no big deal.
Someone would need to care enough to test and implement it though.
> Other useful feature is some way to share a single process between PID
> containers as like a container bridge. For containers used for
> desktop applications not having a single X11 server interfacing with
> video card is a issue.
X allows network connections, and I think unix domain sockets will work.
The latter I need to check on.
The pid namespace is well defined and no a task will not be able
to change it's pid namespace while running. That is nasty.
> These container bridges avoid having to go threw network cards and
> other means to share data between containers. A user space solution.
There are lots of opportunities for user space solutions.
> I know this reduces secuirty but when you need a application form X
> distrobuton and you have Y distribution and its opengl heavy you are
> kinda stuffed at moment.
>
> Final one is some form of LSM processing different. Lot of the Linux
> Secuirty channel talk about containers as light weight virtualisation
> so will never need to run a OS inside with a different LSM profile to
> the master OS. If containers plan to go after brandz like containers
> this needs to be made clear that LSM different processing will be
> required.
We have had that discussion mostly this appears to be a measure of
matureness.
Eric
next prev parent reply other threads:[~2008-07-21 12:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-21 11:03 Roadmap for features planed for containers where and Some future features ideas Peter Dolding
[not found] ` <e7d8f83e0807210403g12b980e8jad4fa7e10d8b410e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-21 12:13 ` Eric W. Biederman [this message]
[not found] ` <m1k5ffmo48.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-07-21 13:21 ` Peter Dolding
[not found] ` <e7d8f83e0807210621y74ef1307x1c0ecbfb33182e85-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-22 1:28 ` Eric W. Biederman
[not found] ` <m1y73uk8qc.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-07-22 14:05 ` Oren Laadan
[not found] ` <4885E927.7070505-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-07-23 0:56 ` Peter Dolding
[not found] ` <e7d8f83e0807221756y18ab14b6mfd8013b2e3424257-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-24 18:32 ` Oren Laadan
[not found] ` <4888CACB.1000600-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2008-07-25 3:32 ` Peter Dolding
[not found] ` <e7d8f83e0807242032p3c93b3dbqcd5f4d44aad9ca6f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-26 7:05 ` Eric W. Biederman
[not found] ` <m1od4lruq8.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-07-26 10:06 ` Peter Dolding
[not found] ` <e7d8f83e0807260306q194be9e9q53151abcea818624-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-26 13:56 ` Eric W. Biederman
[not found] ` <m14p6cpx42.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-07-27 5:17 ` Peter Dolding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1k5ffmo48.fsf@frodo.ebiederm.org \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=oiaohm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox