From: Steve Dickson <SteveD@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have (ver 2)
Date: Wed, 23 Nov 2011 09:40:08 -0500 [thread overview]
Message-ID: <4ECD05C8.3050809@RedHat.com> (raw)
In-Reply-To: <20111122205551.GF21451@fieldses.org>
On 11/22/2011 03:55 PM, J. Bruce Fields wrote:
> On Thu, Nov 17, 2011 at 04:51:34PM -0500, Steve Dickson wrote:
>> In working with the new idmapper, it became very apparent that
>> keys created from bad id mapping were very persistent and were
>> not easy disposed of. Unlike with rpc.idmapd, to git rid
>> of bad id mapping one just needed to restart the daemon.
>>
>> So I've added some functionality to the nfsidmap command
>
> I wonder whether the nfsidmap command is the right place to do that.
> Currently it's only ever invoked by the kernel, and it seems a little
> odd to use the same command as an admin tool as well. But I don't have
> a different suggestion.
Keeping all the "key management" stuff in one place makes sense to me.
>
> Also, just out of curiosity: when were you typically running into this
> problem? And if it was changing some sort of name-mapping
> configuration, is there some way to get this invoked automatically when
> that configuration changes?
Mostly syntax errors in /etc/request-key.conf and when a mapping
didn't happen due to a bug in libnfsidmap...
Also naming resolution mechanisms are not perfect... there will
be errors that will cause mapping failures.
What really caught my eye was with rpc.idmapd, to clear bad mappings,
you just restart the daemon. Now that rpc.idmapd will no longer
need to run on the client (which is a good thing), I wanted to give
the admins some type of mechanism to clean up bad mappings.
steved.
>
> --b.
>
>> that will allow admins to:
>>
>> - remove all the keys on the keyring.
>> - remove a particular key from the keying.
>>
>> The intention is to allow admins a way to clean up the id
>> name space when name resolution mechanisms, like NIS or LDAP,
>> fail and leave a large number (or small number) of id mapping
>> pointing to nobody.
>>
>> Note, for the second patch to work, there need to be a small
>> kernel patch that will change the per-key permissions to
>> allow root to revoke them.
>>
>> Version 2:
>> - Added the fclose() calls as requested by the code review
>>
>> Steve Dickson (2):
>> nfsidmap: Allow all keys to clear on the keyring
>> nfsidmap: Allow a particular key to be revoked.
>>
>> utils/nfsidmap/nfsidmap.c | 145 +++++++++++++++++++++++++++++++++++++++++--
>> utils/nfsidmap/nfsidmap.man | 27 ++++++++-
>> 2 files changed, 166 insertions(+), 6 deletions(-)
>>
>> --
>> 1.7.7
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-11-23 14:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 21:51 [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have (ver 2) Steve Dickson
2011-11-17 21:51 ` [PATCH 1/2] nfsidmap: Allow all keys to clear on the keyring Steve Dickson
2011-11-22 20:53 ` J. Bruce Fields
2011-11-23 14:21 ` Steve Dickson
2011-11-17 21:51 ` [PATCH 2/2] nfsidmap: Allow a particular key to be revoked Steve Dickson
2011-11-22 20:55 ` [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have (ver 2) J. Bruce Fields
2011-11-23 14:40 ` Steve Dickson [this message]
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=4ECD05C8.3050809@RedHat.com \
--to=steved@redhat.com \
--cc=bfields@fieldses.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.