On Sat, 2017-05-27 at 17:45 +, Trond Myklebust wrote:
> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
> > David Howells writes:
> >
> > > Here are a set of patches to define a container object for the
> > > kernel and
> > > to provide some methods to create and manipulate them.
On Sat, 2017-05-27 at 17:45 +, Trond Myklebust wrote:
> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
> > David Howells writes:
> >
> > > Here are a set of patches to define a container object for the
> > > kernel and
> > > to provide some methods to create and manipulate them.
On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
> David Howells writes:
>
> > Here are a set of patches to define a container object for the
> > kernel and
> > to provide some methods to create and manipulate them.
> >
> > The reason I think this is necessary is that the kernel has n
On Wed, 2017-05-24 at 03:26 -0500, Eric W. Biederman wrote:
>
> So far no one has even bothered to seriously try the one solution that
> is guaranteed to work because it takes a lot of changes to kernel code.
> I believe the last effort snagged on what a pain it is to refactor the
> user mode help
David Howells writes:
> James Bottomley wrote:
>
>> What David is pointing out is that the kernel has a DNS cache
>> (net/dns_resolver/) it can do name to IP translations, but isn't
>> namespaced. Once it has one entry all containers would see it if they
>> cause a lookup to go through the kern
James Bottomley wrote:
> What David is pointing out is that the kernel has a DNS cache
> (net/dns_resolver/) it can do name to IP translations, but isn't
> namespaced. Once it has one entry all containers would see it if they
> cause a lookup to go through the kernel cache, so going through the
Eric W. Biederman wrote:
> Let me suggest a concrete alternative:
>
> - At the time of mount observer the mounters user namespace.
Looking at sget(), I don't think a mounter can see a superblock outside of
their namespace. There is something icky in there whereby all automounts are
currently t
On Tue, 2017-05-23 at 10:17 -0500, Eric W. Biederman wrote:
> David Howells writes:
> > Eric W. Biederman wrote:
> > > It does solve this in userspace rather simply.
> >
> > Ummm... How? The kernel DNS resolver is not namespace aware.
>
> But it works fine if called in the proper context and
David Howells writes:
> Here are a set of patches to define a container object for the kernel and
> to provide some methods to create and manipulate them.
Just so this discussion has some clarity.
Nacked-by: "Eric W. Biederman"
As a user visible entity I see nothing this container data struct
On Tue, May 23, 2017, at 11:31 AM, Jeff Layton wrote:
>
> nfsdcltrack was originally nfsdcld, a long running daemon that used
> rpc_pipefs to talk to the kernel. That meant that you had to make sure
> it gets enabled by systemd (or sysvinit, etc). If it dies, then you also
> want to ensure that it
On Tue, 2017-05-23 at 10:54 -0400, Colin Walters wrote:
> On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote:
> >
> > Maybe it depends on the cases, a general approach can be too difficult
> > to handle especially from the security point. Maybe it is better to
> > identify what operations nee
David Howells writes:
> Another thing that could be useful is a list of what device files a container
> may access, so that we can allow limited mounting by the container root user
> within the container.
That is totally not why that isn't allowed, and won't be allowed any
time soon.
The issue
Colin Walters wrote:
> Why not drop the upcall model in favor of having userspace monitor events
> via a (more efficient) protocol and react to them on its own?
(1) That's not necessarily more efficient. You now have the overhead of a
permanently running userspace daemon in every relevant
David Howells writes:
> Eric W. Biederman wrote:
>
>> > As an example, I could set up a client machine with two ethernet ports,
>> > set up two DNS+NFS servers, each of which think they're called "foo.bar"
>> > and attach each server to a different port on the client machine. Then I
>> > could
Eric W. Biederman wrote:
> > As an example, I could set up a client machine with two ethernet ports,
> > set up two DNS+NFS servers, each of which think they're called "foo.bar"
> > and attach each server to a different port on the client machine. Then I
> > could create a pair of containers on
Jessica Frazelle wrote:
> Adding a container object seems a bit odd to me because there are so
> many different ways to make containers, aka not all namespaces are
> always used
This is already dealt with to some extent. It can create/inherit namespaces
like fork - except that you get an extra
David Howells writes:
> Aleksa Sarai wrote:
>
>> >> The reason I think this is necessary is that the kernel has no idea
>> >> how to direct upcalls to what userspace considers to be a container -
>> >> current Linux practice appears to make a "container" just an
>> >> arbitrarily chosen junction
On Tue, 2017-05-23 at 14:52 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > This sounds like a step in the wrong direction: the strength of the
> > current container interfaces in Linux is that people who set up
> > containers don't have to agree what they look like.
>
> It may be a s
On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote:
>
> Maybe it depends on the cases, a general approach can be too difficult
> to handle especially from the security point. Maybe it is better to
> identify what operations need what context, and a userspace
> service/proxy can act using kthre
Aleksa Sarai wrote:
> >> The reason I think this is necessary is that the kernel has no idea
> >> how to direct upcalls to what userspace considers to be a container -
> >> current Linux practice appears to make a "container" just an
> >> arbitrarily chosen junction of namespaces, control groups
On Tue, May 23, 2017 at 2:54 PM, Eric W. Biederman
wrote:
> Jeff Layton writes:
>
>> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
>>> David Howells writes:
>>>
>>> > Here are a set of patches to define a container object for the kernel and
>>> > to provide some methods to create a
On Tue, 2017-05-23 at 07:54 -0500, Eric W. Biederman wrote:
> Jeff Layton writes:
>
> > On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
> > > David Howells writes:
> > >
> > > > Here are a set of patches to define a container object for the kernel
> > > > and
> > > > to provide som
On Tue, May 23, 2017 at 12:22 AM, Jeff Layton wrote:
> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
>> David Howells writes:
>>
>> > Here are a set of patches to define a container object for the kernel and
>> > to provide some methods to create and manipulate them.
>> >
>> > The r
James Bottomley wrote:
> This sounds like a step in the wrong direction: the strength of the
> current container interfaces in Linux is that people who set up
> containers don't have to agree what they look like.
It may be a strength, but it is also a problem.
> So I can set up a user namespace
Jeff Layton writes:
> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
>> David Howells writes:
>>
>> > Here are a set of patches to define a container object for the kernel and
>> > to provide some methods to create and manipulate them.
>> >
>> > The reason I think this is necessar
On Mon, 2017-05-22 at 12:21 -0700, James Bottomley wrote:
>
> > > > (3) nfsdcltrack. A way for NFSD to access stable storage for
> > > > tracking of persistent state. Again, network-namespace
> > > > dependent, but also perhaps mount-namespace dependent.
> >
> > Definitely mount-namespace de
On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> Here are a set of patches to define a container object for the kernel and
> to provide some methods to create and manipulate them.
>
> The reason I think this is necessary is that the kernel has no idea how to
> direct upcalls to what users
On Mon, 2017-05-22 at 09:53 -0700, James Bottomley wrote:
> [Added missing cc to containers list]
> On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> > Here are a set of patches to define a container object for the kernel
> > and to provide some methods to create and manipulate them.
> >
On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
> David Howells writes:
>
> > Here are a set of patches to define a container object for the kernel and
> > to provide some methods to create and manipulate them.
> >
> > The reason I think this is necessary is that the kernel has no id
On Mon, 2017-05-22 at 12:21 -0700, James Bottomley wrote:
> On Mon, 2017-05-22 at 14:34 -0400, Jeff Layton wrote:
> > On Mon, 2017-05-22 at 09:53 -0700, James Bottomley wrote:
> > > [Added missing cc to containers list]
> > > On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> > > > Here are
On Mon, 2017-05-22 at 14:34 -0400, Jeff Layton wrote:
> On Mon, 2017-05-22 at 09:53 -0700, James Bottomley wrote:
> > [Added missing cc to containers list]
> > On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> > > Here are a set of patches to define a container object for the
> > > kernel
David Howells writes:
> Here are a set of patches to define a container object for the kernel and
> to provide some methods to create and manipulate them.
>
> The reason I think this is necessary is that the kernel has no idea how to
> direct upcalls to what userspace considers to be a container
On Mon, 2017-05-22 at 09:53 -0700, James Bottomley wrote:
> [Added missing cc to containers list]
> On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> > Here are a set of patches to define a container object for the kernel
> > and to provide some methods to create and manipulate them.
> >
I had replied but not to the thread with the containers mailing list.
See https://marc.info/?l=linux-cgroups&m=149547317006676&w=2
On Mon, May 22, 2017 at 5:53 PM, James Bottomley
wrote:
> [Added missing cc to containers list]
> On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
>> Here are
The reason I think this is necessary is that the kernel has no idea
how to direct upcalls to what userspace considers to be a container -
current Linux practice appears to make a "container" just an
arbitrarily chosen junction of namespaces, control groups and files,
which may be changed individua
This is interesting...
Adding a container object seems a bit odd to me because there are so
many different ways to make containers, aka not all namespaces are
always used as well as not all cgroups, various LSM objects sometimes
apply, mounts blah blah blah. The OCI spec was made to cover all thes
[Added missing cc to containers list]
On Mon, 2017-05-22 at 17:22 +0100, David Howells wrote:
> Here are a set of patches to define a container object for the kernel
> and to provide some methods to create and manipulate them.
>
> The reason I think this is necessary is that the kernel has no ide
Here are a set of patches to define a container object for the kernel and
to provide some methods to create and manipulate them.
The reason I think this is necessary is that the kernel has no idea how to
direct upcalls to what userspace considers to be a container - current
Linux practice appears
38 matches
Mail list logo
