Serge Hallyn writes:
> So apart from peers seeing the new task as having pid 0, and
> sigchild going to the grandparent, are there any other side
> effects? Is ptrace an issue? (I took a quick look but it
> doesn't seem like it)
There is nothing new the pid namespace adds to the pid namespace
Oleg Nesterov writes:
> Hi Serge,
>
> On 11/06, Serge Hallyn wrote:
>>
>> Hi Oleg,
>>
>> commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e :
>> "fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks"
>> breaks lxc-attach in 3.12. That code forks a child which does
>> setns() and then does a
Sean Pajot writes:
> On 10/22/2013 03:50 PM, Eric W. Biederman wrote:
>> Serge Hallyn writes:
>>
>>> Quoting Sean Pajot (sean.pa...@execulink.com):
>>>> I've been playing with User Namespaces somewhat extensively and I think
>>>> I&#x
Serge Hallyn writes:
> Quoting Sean Pajot (sean.pa...@execulink.com):
>> I've been playing with User Namespaces somewhat extensively and I think I've
>> come across a bug in the handling of /proc/$PID/ entries.
>>
>> This is my example case on a 3.10.x kernel:
>>
>> -- /var/lib/lxc/test1/config
Amir Goldstein writes:
> Excellent! let's focus the discussion on a new device driver we want
> to write
> which is namespace aware. let's call this device driver valarm-dev.
> Similarly to Android's alarm-dev, valarm-dev can be used to request
> RTC wakeup calls
> from user space and get/set RTC
ebied...@xmission.com (Eric W. Biederman) writes:
>> This kind of API is a required building block for us to write device
>> drivers that are namespace aware in a way that userspace will have
>> enough flexibility for dynamic configuration.
>>
>> We are trying to co
Amir Goldstein writes:
> What we really like to see is a setns() style API that can be used to
> add a device in the context of a namespace in either a "shared" or
> "private" mode.
I think you mean an "ip link set dev FOO netns XXX" style API.
Right now one of the best suggestions on the table
Serge Hallyn writes:
>> Glossing over the details. The general problem is some policy exists
>> outside of the container that deciedes if an when a container gets a
>> serial port and stuffs it in.
>>
>> The expectation is that system containers will then run the udev
>> rules and send the libu
I think libudev is a solution to a completely different problem. It is
possible I am blind but I just don't see how libudev even attempts to
solve the problem.
The desire is to plop a distro install into a subdirectory. Fire up a
container around it, and let the distro's userspace do it's thing
"Serge E. Hallyn" writes:
> Quoting Andy Lutomirski (l...@amacapital.net):
>> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
>> wrote:
>> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
>> > wrote:
>> >
>> >>> - We can relay a call of /sbin/hotplug from outside of a container
>> >>> to
>From conversations at Linux Plumbers Converence it became fairly clear
that one if not the roughest edge on containers today is dealing with
devices.
- Hotplug does not work.
- There seems to be no implementation that does a much beyond creating
setting up a static set of /dev entries today.
-
Jeremy Andrus writes:
> On Sep 25, 2013, at 4:23 PM, Eric W. Biederman wrote:
>
>> Janne Karhunen writes:
>>
>>> That being said, is there a valid reason why binder is part of device
>>> namespace here instead of IPC?
>>
>> I think the practic
Janne Karhunen writes:
> That being said, is there a valid reason why binder is part of device
> namespace here instead of IPC?
I think the practical issue with binder was simply that binder only
allows for a single instance and thus is does not play nicely with
containers.
Eric
-
Amir Goldstein writes:
> On Fri, Sep 6, 2013 at 7:50 PM, Eric W. Biederman
> wrote:
>
> Hi Eric,
>
> If we can get people to take a quick look at the code before LPC
> that could make the LPC discussions more effective.
> Even looking at one of the subsystem patches ca
Oren Laadan writes:
> Hi Serge,
>
>
> On Thu, Aug 22, 2013 at 2:21 PM, Serge Hallyn wrote:
>
>> Quoting Oren Laadan (or...@cellrox.com):
>> > Hi everyone!
>> >
>> > We [1] have been working on bringing lightweight virtualization to
>> > Linux-based mobile devices like Android (or other Linux-base
Gao feng writes:
> right now I only take note of the unix socket /run/systemd/private,
> but there may have many similar unix sockets, they can exist in any
> path. the strange problems will still happen.
It could just as easily have been a fifo in the filesystem, and the
result would have been
Gao feng writes:
> cc libvirt-list
>
> On 08/21/2013 01:30 PM, Eric W. Biederman wrote:
>> Gao feng writes:
>>
>>> Unix sockets are private resources of net namespace,
>>> allowing one net namespace to access to other netns's unix
>>> sock
own -h now
There are more compelling uses and there is no cost in supporting this
in the kernel.
What kind of misconfiguration caused someone to complain about this?
> We should make sure unix sockets are per net namespace to
> avoid this problem.
Nacked-by: "Eric W. Biederm
e bad guys
are going to do with it.
Eric
> On Wed, 6 Mar 2013 09:58:53 -0600
> Serge Hallyn wrote:
>
>> Quoting Dwight Engen (dwight.en...@oracle.com):
>> > On Mon, 25 Feb 2013 20:26:21 -0800
>> > ebied...@xmission.com (Eric W. Biederman) wrote:
>>
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> richard -rw- weinberger writes:
>>
>> > On Thu, Apr 11, 2013 at 7:03 AM, Eric W. Biederman
>> > wrote:
>> >> richard -rw- weinberger writes:
>> >>> {st_mod
richard -rw- weinberger writes:
> On Thu, Apr 11, 2013 at 5:03 PM, Eric W. Biederman
> wrote:
>> richard -rw- weinberger writes:
>>
>>> On Thu, Apr 11, 2013 at 7:03 AM, Eric W. Biederman
>>> wrote:
>>>> richard -rw- weinberger writes:
&
richard -rw- weinberger writes:
> On Thu, Apr 11, 2013 at 7:03 AM, Eric W. Biederman
> wrote:
>> richard -rw- weinberger writes:
>>> {st_mode=S_IFCHR|0644, st_rdev=makedev(5, 1), ...}) = 0
>>> [pid 3100] chmod("/dev/pts/5", 020644) = -1 EPERM (Operati
richard -rw- weinberger writes:
> On Wed, Apr 10, 2013 at 8:55 PM, Serge Hallyn wrote:
>> Quoting richard -rw- weinberger (richard.weinber...@gmail.com):
>>> This one?
>>> https://launchpad.net/~ubuntu-lxc/+archive/kernel/+packages
>>>
>>> I'm not an Ubuntu guy and not very familiar with this pp
Michael J Coss writes:
> On 3/18/2013 11:45 PM, Eric W. Biederman wrote:
>> I will say what I have said elsewhere recently to ensure the idea
>> percolates. What can be implemented now without kernel support and
>> that is interesting is devtmpfs emulation. That is a tmpfs
Serge Hallyn writes:
>> But getting back to the question of policy, does it make sense that the
>> way policy is implemented
>
> Policy is not implemented.
>
>> is that the all containers receive the events,
>> and container configuration determines what uevents should/can be
>> processed by t
"Timofey.Kirillov" writes:
> Hi,
>
> I have a question about using unnamed pipes with procfs.
>
> Suppose a chrooted environment with proc mounted as procfs. I am trying
> to use bash process substitution feature and get this:
>
> $ cat <(echo hello)
> cat: /dev/fd/63: No such file or directory
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
> ...
>> For what it's worth. If you are going to do a combined binary, and you
>> are just going to worry about yourself. You don't have to fork to
>> write /proc/self/uid_map with
Kees Cook writes:
> On Wed, Mar 6, 2013 at 2:25 PM, Serge Hallyn wrote:
>> just to help play with user namespaces some more I pushed a C version
>> of Eric's script for completely unprivileged use of user namespaces to
>> https://code.launchpad.net/~serge-hallyn/+junk/nsexec and to the
>> nsexec
Dwight Engen writes:
> On Sun, 24 Feb 2013 21:12:59 -0800
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>> Serge Hallyn writes:
>>
>> > Quoting Dwight Engen (dwight.en...@oracle.com):
>> >> I finally got around to testing out user namespaces.
Serge Hallyn writes:
> Quoting Dwight Engen (dwight.en...@oracle.com):
>> I finally got around to testing out user namespaces. Very nice to to
>> have container root not be kuid 0! One thing that I noticed was that
>> mingetty in the container was failing because the call to vhangup(2)
>> failed
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> Serge Hallyn writes:
>>
>> > Quoting Michael H. Warfield (m...@wittsend.com):
>> >> On Wed, 2013-01-16 at 16:46 -0600, Serge Hallyn wrote:
>> >> > Quoting Micha
Serge Hallyn writes:
> Quoting Michael H. Warfield (m...@wittsend.com):
>> On Wed, 2013-01-16 at 16:46 -0600, Serge Hallyn wrote:
>> > Quoting Michael H. Warfield (m...@wittsend.com):
>> > > Serge,
>> > >
>> > > Revisiting an earlier remark...
>> > ...
>> > > > Now I tested, and with a simple se
Serge Hallyn writes:
> Hi,
>
> Now that the core user namespace support is in both the 3.8 kernel
> and in the lxc staging branch, I thought it might be good to have
> a meeting to first make sure everyone understands what it is and
> what it can do, and second to discuss a path for what we want
Daniel Lezcano writes:
> Hi Serge,
>
> thanks for the pointer.
>
> I though it was for user ns only.
The pieces were closely interrelated so I used the same tree.
> Cool to see Eric is taking care of the final bits of this feature.
My apologies for letting it languish so long. That wasn't my
Dusty Hall writes:
> Is there any reason why I'm seeing other lxc's drop their network
> connections when I stop or start another lxc? I'm running a bridging
> network with static ip's on lxc's, see below. This is happening on
> both Ubuntu pkgs: 0.7.4-0ubuntu7.3 & 0.7.5-3ubuntu59. Any advice
Serge Hallyn writes:
> Quoting Christian Seiler (christ...@iwakd.de):
>> This patch adds the -s/--namespaces option to lxc-attach that works
>> analogously to lxc-unshare, allowing the user to select the namespaces the
>> process should be attached to.
>>
>> User namespaces are supported, under
Michael Tokarev writes:
> [Replying to an oldish email...]
>
> On 12.10.2011 20:59, Kay Sievers wrote:
>> On Mon, Oct 10, 2011 at 23:41, Lennart Poettering
>> wrote:
>>> On Mon, 10.10.11 13:59, Eric W. Biederman (ebied...@xmission.com) wrote:
>>
>>&g
Ted Ts'o writes:
>> I am of course making it sound a million times easier than it's
>> actually likely to be, but I do think it's possible without too many
>> odd corner cases.
>
> It's not the corner cases, it's all of the different name spaces that
> different system administrators and their si
Theodore Tso writes:
> On Oct 11, 2011, at 2:42 AM, Eric W. Biederman wrote:
>
>> I am totally in favor of not starting the entire world. But just
>> like I find it convienient to loopback mount an iso image to see
>> what is on a disk image. It would be handy to be ab
da...@lang.hm writes:
> On Tue, 11 Oct 2011, Eric W. Biederman wrote:
>
>> Theodore Tso writes:
>>
>>> On Oct 11, 2011, at 2:42 AM, Eric W. Biederman wrote:
>>>
>>>> I am totally in favor of not starting the entire world. But just
>>>&g
Lennart Poettering writes:
> On Mon, 10.10.11 13:59, Eric W. Biederman (ebied...@xmission.com) wrote:
>
>> > Quite a few kernel subsystems are
>> > currently not virtualized, for example SELinux, VTs, most of sysfs, most
>> > of /proc/sys, audit, udev or file sy
Cc's and subject updated so hopefully we get the correct people
on this discussion to make progress.
Lennart Poettering writes:
> To make a standard distribution run nicely in a Linux container you
> usually have to make quite a number of modifications to it and disable
> certain things from th
Ted Ts'o writes:
> On Mon, Oct 10, 2011 at 07:05:30PM -0700, Matt Helsley wrote:
>> Yes, it does detract from the unique advantages of using a container.
>> However, I think the value here is not the effeciency of the initial
>> system configuration but the fact that it gives users a better place
Lennart Poettering writes:
> On Mon, 10.10.11 13:59, Eric W. Biederman (ebied...@xmission.com) wrote:
>> My list of things that still have work left to do looks like:
>> - cgroups. It is not safe to create a new hierarchies with groups
>> that are in existing hierarchi
44 matches
Mail list logo
