linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have (ver 2)
@ 2011-11-17 21:51 Steve Dickson
  2011-11-17 21:51 ` [PATCH 1/2] nfsidmap: Allow all keys to clear on the keyring Steve Dickson
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Steve Dickson @ 2011-11-17 21:51 UTC (permalink / raw)
  To: Linux NFS Mailing List

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
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


^ permalink raw reply	[flat|nested] 11+ messages in thread
* [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have (ver 3)
@ 2011-11-23 15:24 Steve Dickson
  2011-11-23 15:24 ` [PATCH 2/2] nfsidmap: Allow a particular key to be revoked Steve Dickson
  0 siblings, 1 reply; 11+ messages in thread
From: Steve Dickson @ 2011-11-23 15:24 UTC (permalink / raw)
  To: Linux NFS Mailing List

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
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
Version 3:
- Confined the -c flag to only remove keys from the id_resolver keyring.

Steve Dickson (2):
  nfsidmap: Allow keys to be cleared from the keyring
  nfsidmap: Allow a particular key to be revoked.

 utils/nfsidmap/nfsidmap.c   |  148 +++++++++++++++++++++++++++++++++++++++++--
 utils/nfsidmap/nfsidmap.man |   25 +++++++-
 2 files changed, 167 insertions(+), 6 deletions(-)

-- 
1.7.7


^ permalink raw reply	[flat|nested] 11+ messages in thread
* [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have failed
@ 2011-11-17 20:26 Steve Dickson
  2011-11-17 20:26 ` [PATCH 2/2] nfsidmap: Allow a particular key to be revoked Steve Dickson
  0 siblings, 1 reply; 11+ messages in thread
From: Steve Dickson @ 2011-11-17 20:26 UTC (permalink / raw)
  To: Linux NFS Mailing List

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
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.

Steve Dickson (2):
  nfsidmap: Allow all keys to clear on the keyring
  nfsidmap: Allow a particular key to be revoked.

 utils/nfsidmap/nfsidmap.c   |  138 +++++++++++++++++++++++++++++++++++++++++--
 utils/nfsidmap/nfsidmap.man |   27 ++++++++-
 2 files changed, 159 insertions(+), 6 deletions(-)

-- 
1.7.7


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2011-11-23 15:24 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
  -- strict thread matches above, loose matches on Subject: below --
2011-11-23 15:24 [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have (ver 3) Steve Dickson
2011-11-23 15:24 ` [PATCH 2/2] nfsidmap: Allow a particular key to be revoked Steve Dickson
2011-11-17 20:26 [PATCH 0/2] nfsidmap: Allow admins to clean up id mappings that have failed Steve Dickson
2011-11-17 20:26 ` [PATCH 2/2] nfsidmap: Allow a particular key to be revoked Steve Dickson
2011-11-17 20:34   ` Tigran Mkrtchyan
2011-11-17 21:36     ` Steve Dickson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).