From: "David Härdeman" <david@hardeman.nu>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: David Howells <dhowells@redhat.com>,
ikent@redhat.com, bcodding@redhat.com, linux-nfs@vger.kernel.org,
SteveD@redhat.com
Subject: Re: [PATCH 00/19] gssd improvements
Date: Wed, 10 Dec 2014 21:55:52 +0100 [thread overview]
Message-ID: <20141210205552.GB11396@hardeman.nu> (raw)
In-Reply-To: <20141210140311.7fb7b159@tlielax.poochiereds.net>
On Wed, Dec 10, 2014 at 02:03:11PM -0500, Jeff Layton wrote:
>On Wed, 10 Dec 2014 16:03:02 +0000
>David Howells <dhowells@redhat.com> wrote:
>> Jeff Layton <jeff.layton@primarydata.com> wrote:
>> > > This thread might be interesting:
>> > > https://lkml.org/lkml/2014/11/24/885
>> > >
>> >
>> > Nice. I wasn't aware that Ian was working on this. I'll take a look.
>>
>> I'm not sure what the current state of this is. There was some discussion
>> over how best to determine which container we need to run in - and it's
>> complicated by the fact that the mounter may run in a different container to
>> the program that triggered the mount due to mountpoint propagation.
>>
>
>Yes. It's quite a thorny problem.
>
>Part of the issue is that the different namespaces (net, mount, etc...)
>are completely orthogonal to one another as far as the kernel is
>concerned, but they really can't be when we start talking about
>userland stuff.
>
>For example, all of the nfs and nfsd namespace code was tied to the net
>namespace. But, once you start involving things like gssd, the mount
>namespace matters too as it has to deal with files (libraries and
>config files, in particular).
>
>Q: What happens if you have two "containers" that have the same net
>namespace but different mount namespaces along with a different krb5
>configuration in each? Maybe even with a gssd running in each?
>
>A: A horrible mess, AFAICT...
>
>Without something that really enforces a 1:1 relationship between all
>of the different sorts of namespaces, the whole container/namespace
>concept quickly descends into a horrid mess. It makes my head hurt.
And crossing namespaces could theoretically be a feature as well
(meaning the 1:1 relationship isn't necessarily wanted)? Imagine
generating krb5 tickets in one container that are used in another
container...(though I might be completely mistaken here)?
Anyway....as far as I can tell...rpc.idmapd, nfsidmap and rpc.gssd all
lack namespace awareness...right? And in particular nfsidmap since it
runs in the root namespace (and the other tools run in whichever
namespace they're launched in, which may or may not be the right one)...
But...maybe that particular problem is not a good reason to hold up e.g.
experimentation with a request-key based gssd util (one that would work
for the "normal" case with no containers and namespaces....)?
--
David Härdeman
next prev parent reply other threads:[~2014-12-10 20:56 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 5:40 [PATCH 00/19] gssd improvements David Härdeman
2014-12-09 5:40 ` [PATCH 01/19] nfs-utils: cleanup daemonization code David Härdeman
2014-12-09 5:40 ` [PATCH 02/19] nfs-utils: gssd - merge gssd_main_loop.c and gssd.c David Härdeman
2014-12-09 5:40 ` [PATCH 03/19] nfs-utils: gssd - simplify some option handling David Härdeman
2014-12-09 5:41 ` [PATCH 04/19] nfs-utils: gssd - remove arbitrary GSSD_MAX_CCACHE_SEARCH limitation David Härdeman
2014-12-09 5:41 ` [PATCH 05/19] nfs-utils: gssd - simplify topdirs path David Härdeman
2014-12-09 5:41 ` [PATCH 06/19] nfs-utils: gssd - move over pipfs scanning code David Härdeman
2014-12-09 5:41 ` [PATCH 07/19] nfs-utils: gssd - simplify client dir " David Härdeman
2014-12-09 5:41 ` [PATCH 08/19] nfs-utils: gssd - use libevent David Härdeman
2014-12-09 5:41 ` [PATCH 09/19] nfs-utils: gssd - remove "close me" code David Härdeman
2014-12-09 5:41 ` [PATCH 10/19] nfs-utils: gssd - make the client lists per-topdir David Härdeman
2014-12-09 5:41 ` [PATCH 11/19] nfs-utils: gssd - keep the rpc_pipefs dir open David Härdeman
2014-12-09 5:41 ` [PATCH 12/19] nfs-utils: gssd - use more relative paths David Härdeman
2014-12-09 5:41 ` [PATCH 13/19] nfs-utils: gssd - simplify topdir scanning David Härdeman
2014-12-09 5:41 ` [PATCH 14/19] nfs-utils: gssd - simplify client scanning David Härdeman
2014-12-09 5:41 ` [PATCH 15/19] nfs-utils: gssd - cleanup read_service_info David Härdeman
2014-12-09 5:42 ` [PATCH 16/19] nfs-utils: gssd - change dnotify to inotify David Härdeman
2014-12-09 5:42 ` [PATCH 17/19] nfs-utils: gssd - further shorten some pathnames David Härdeman
2014-12-09 5:42 ` [PATCH 18/19] nfs-utils: gssd - improve inotify David Härdeman
2014-12-09 5:42 ` [PATCH 19/19] nfs-utils: gssd - simplify handle_gssd_upcall David Härdeman
2014-12-09 13:09 ` [PATCH 00/19] gssd improvements Jeff Layton
2014-12-09 13:52 ` David Härdeman
2014-12-09 14:58 ` Jeff Layton
2014-12-09 15:07 ` Simo Sorce
2014-12-09 19:55 ` David Härdeman
2014-12-10 11:52 ` Jeff Layton
2014-12-10 14:08 ` David Härdeman
2014-12-10 14:17 ` Jeff Layton
2014-12-10 14:31 ` David Härdeman
2014-12-10 14:34 ` Jeff Layton
2014-12-10 16:03 ` David Howells
2014-12-10 19:03 ` Jeff Layton
2014-12-10 20:55 ` David Härdeman [this message]
2014-12-10 23:44 ` Ian Kent
2014-12-10 23:21 ` Benjamin Coddington
2014-12-11 0:12 ` Ian Kent
2014-12-11 1:54 ` Benjamin Coddington
2014-12-11 3:21 ` Ian Kent
2014-12-11 11:45 ` Jeff Layton
2014-12-11 12:55 ` Ian Kent
2014-12-11 13:46 ` Jeff Layton
2014-12-11 22:31 ` Ian Kent
2014-12-11 19:32 ` J. Bruce Fields
2014-12-11 19:50 ` Jeff Layton
2014-12-11 19:55 ` J. Bruce Fields
2014-12-11 20:11 ` Jeff Layton
2014-12-11 20:38 ` J. Bruce Fields
2014-12-11 22:20 ` Ian Kent
2014-12-09 16:39 ` Steve Dickson
2014-12-09 20:22 ` David Härdeman
2014-12-09 21:13 ` Steve Dickson
2014-12-10 14:20 ` David Härdeman
2014-12-10 20:35 ` J. Bruce Fields
2014-12-10 20:49 ` David Härdeman
2014-12-10 21:07 ` J. Bruce Fields
2015-01-28 21:29 ` Steve Dickson
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=20141210205552.GB11396@hardeman.nu \
--to=david@hardeman.nu \
--cc=SteveD@redhat.com \
--cc=bcodding@redhat.com \
--cc=dhowells@redhat.com \
--cc=ikent@redhat.com \
--cc=jeff.layton@primarydata.com \
--cc=linux-nfs@vger.kernel.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