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. 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? --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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
