Hi folks,
Does somebody know if it's possible to do secure mounts within linux
containers? I seem to recall that gssd is not container-aware. Or is
container-magic makes it so that gssd runs per container and has its
own dedicated krb5.conf+keytab configurations?
Thank you.
On Thu, 14 Apr 2016, Olga Kornievskaia wrote:
> Hi folks,
>
> Does somebody know if it's possible to do secure mounts within linux
> containers? I seem to recall that gssd is not container-aware. Or is
> container-magic makes it so that gssd runs per container and has its
> own dedicated krb5.conf+keytab configurations?
>
> Thank you.
Hi Olga,
As far as I know there's no good way to run multiple gssd inside containers.
There's only one global upcall mechanism, so even if we could keep track of
which container is doing IO, there doesn't exist a way to upcall to the
appropriate gssd. Additionally, containers are a collection of shared
namespaces. A gssd could share one or more of those namespaces with a
process doing IO, so what sort of rules do we use to pick the right gssd?
Ian Kent has led some discussion on solving this, and right now the thinking
is to always upcall into whichever namespace collection created the mount,
but the bet way to preserve those namespaces has not been agreed upon yet.
Ben
On Thu, Apr 14, 2016 at 02:57:51PM -0400, Benjamin Coddington wrote:
> On Thu, 14 Apr 2016, Olga Kornievskaia wrote:
>
> > Hi folks,
> >
> > Does somebody know if it's possible to do secure mounts within linux
> > containers? I seem to recall that gssd is not container-aware. Or is
> > container-magic makes it so that gssd runs per container and has its
> > own dedicated krb5.conf+keytab configurations?
> >
> > Thank you.
On the server side it should work in theory, I don't know if anyone's
tested it. On the client side:
> As far as I know there's no good way to run multiple gssd inside containers.
> There's only one global upcall mechanism, so even if we could keep track of
> which container is doing IO, there doesn't exist a way to upcall to the
> appropriate gssd. Additionally, containers are a collection of shared
> namespaces. A gssd could share one or more of those namespaces with a
> process doing IO, so what sort of rules do we use to pick the right gssd?
>
> Ian Kent has led some discussion on solving this, and right now the thinking
> is to always upcall into whichever namespace collection created the mount,
> but the bet way to preserve those namespaces has not been agreed upon yet.
Isn't the client side still using the rpc_pipefs upcall? That might
still need containerization work. But that's different than the problem
Ian was looking at with running usermode helpers. Making gssd work
might be easier.
--b.
On Mon, 18 Apr 2016, J. Bruce Fields wrote:
> On Thu, Apr 14, 2016 at 02:57:51PM -0400, Benjamin Coddington wrote:
> > On Thu, 14 Apr 2016, Olga Kornievskaia wrote:
> >
> > > Hi folks,
> > >
> > > Does somebody know if it's possible to do secure mounts within linux
> > > containers? I seem to recall that gssd is not container-aware. Or is
> > > container-magic makes it so that gssd runs per container and has its
> > > own dedicated krb5.conf+keytab configurations?
> > >
> > > Thank you.
>
> On the server side it should work in theory, I don't know if anyone's
> tested it. On the client side:
>
> > As far as I know there's no good way to run multiple gssd inside containers.
> > There's only one global upcall mechanism, so even if we could keep track of
> > which container is doing IO, there doesn't exist a way to upcall to the
> > appropriate gssd. Additionally, containers are a collection of shared
> > namespaces. A gssd could share one or more of those namespaces with a
> > process doing IO, so what sort of rules do we use to pick the right gssd?
> >
> > Ian Kent has led some discussion on solving this, and right now the thinking
> > is to always upcall into whichever namespace collection created the mount,
> > but the bet way to preserve those namespaces has not been agreed upon yet.
>
> Isn't the client side still using the rpc_pipefs upcall? That might
> still need containerization work. But that's different than the problem
> Ian was looking at with running usermode helpers. Making gssd work
> might be easier.
Yes, the client is still using rpc_pipefs for gssd, and it does need
containerization work. My understanding is that when containerized
usermode helpers are solved, gssd would move to them since putting
credentials on keyrings would be a convenient way to have multiple
creds per uid.
Ben
On Mon, Apr 18, 2016 at 04:04:24PM -0400, Benjamin Coddington wrote:
> On Mon, 18 Apr 2016, J. Bruce Fields wrote:
>
> > On Thu, Apr 14, 2016 at 02:57:51PM -0400, Benjamin Coddington wrote:
> > > On Thu, 14 Apr 2016, Olga Kornievskaia wrote:
> > >
> > > > Hi folks,
> > > >
> > > > Does somebody know if it's possible to do secure mounts within linux
> > > > containers? I seem to recall that gssd is not container-aware. Or is
> > > > container-magic makes it so that gssd runs per container and has its
> > > > own dedicated krb5.conf+keytab configurations?
> > > >
> > > > Thank you.
> >
> > On the server side it should work in theory, I don't know if anyone's
> > tested it. On the client side:
> >
> > > As far as I know there's no good way to run multiple gssd inside containers.
> > > There's only one global upcall mechanism, so even if we could keep track of
> > > which container is doing IO, there doesn't exist a way to upcall to the
> > > appropriate gssd. Additionally, containers are a collection of shared
> > > namespaces. A gssd could share one or more of those namespaces with a
> > > process doing IO, so what sort of rules do we use to pick the right gssd?
> > >
> > > Ian Kent has led some discussion on solving this, and right now the thinking
> > > is to always upcall into whichever namespace collection created the mount,
> > > but the bet way to preserve those namespaces has not been agreed upon yet.
> >
> > Isn't the client side still using the rpc_pipefs upcall? That might
> > still need containerization work. But that's different than the problem
> > Ian was looking at with running usermode helpers. Making gssd work
> > might be easier.
>
> Yes, the client is still using rpc_pipefs for gssd, and it does need
> containerization work. My understanding is that when containerized
> usermode helpers are solved, gssd would move to them since putting
> credentials on keyrings would be a convenient way to have multiple
> creds per uid.
Oh, right, makes sense.
--b.