From: "David Härdeman" <david@hardeman.nu>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: linux-nfs@vger.kernel.org, SteveD@redhat.com, dhowells@redhat.com
Subject: Re: [PATCH 00/19] gssd improvements
Date: Wed, 10 Dec 2014 15:08:40 +0100 [thread overview]
Message-ID: <33fa16f69b18ed67e3fd595b95497941@hardeman.nu> (raw)
In-Reply-To: <20141210065240.77a23160@tlielax.poochiereds.net>
On 2014-12-10 12:52, Jeff Layton wrote:
> On Tue, 9 Dec 2014 20:55:30 +0100
> David Härdeman <david@hardeman.nu> wrote:
>> Another question that comes to mind...if we're anyway forking a child
>> per gssd request...how far has the idea of changing rpc.gssd over to a
>> /sbin/request-key helper been considered? I've seen some traces of
>> historical discussions via google but nothing concrete so far...
>>
>
> (cc'ing David in case I'm wrong on this point)
>
> Yes. The problem with keyrings is that while the in-kernel parts are
> namespace-aware, the upcalls are not. /sbin/request-key is spawned by a
> kernel thread that lives in the init namespaces. Any solution that
> involves a usermodehelper upcall will need to figure out how to handle
> containerized clients.
>
> Another idea might be to scrap rpc.gssd altogether and communicate with
> gssproxy directly (but that too involves running a daemon, of course).
I'm not sure I follow completely...first of all, rpc.gssd is also not
namespace-aware, is it? I mean, sure, it could be run in a given
namespace, but there can still only be one rpc.gssd running?
Also...the nfsidmap binary (the request-key helper) isn't
namespace-aware...is it?
//David
next prev parent reply other threads:[~2014-12-10 14:08 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 [this message]
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
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=33fa16f69b18ed67e3fd595b95497941@hardeman.nu \
--to=david@hardeman.nu \
--cc=SteveD@redhat.com \
--cc=dhowells@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