On Thu, 2010-09-30 at 13:23 -0400, J. Bruce Fields wrote: > On Thu, Sep 30, 2010 at 01:07:17PM -0400, Trond Myklebust wrote: > > On Thu, 2010-09-30 at 11:42 -0400, Chuck Lever wrote: > > > Finally, if at all possible, it would be better if the kernel could automatically recognize and use nfs.upcall rather than the legacy idmapping mechanism. My experience with CONFIG options is that people will almost always choose the wrong setting no matter how many large neon arrows you add. I know there are likely some technical challenges here. > > > > I don't think that is easy to do. The keyring upcall mechanism will > > almost always succeed, no matter whether or not there is a handler for > > the type of key requested. Instead, it will result in a negative lookup. > > Unfortunately, seeing a negative key isn't sufficient to determine that > > no handler exists. > > If we could just find out whether there's an executable at the right > path, that would be enough to catch most misconfigurations. Would it be > hard to get back at least that much information? AFAICS, the lookup can return ENOENT or EACCES if the key-utils package is missing. However, as I said above, the fact that the exec succeeds is not sufficient to determine whether or not the user has installed our upcall handler in their /etc/request-key.conf. > I'm inclined to agree with Chuck that this is a likely trap for the > unwary.... That's why the help text for the config option states explicitly that you need new tools, and points you to the correct Documentation file... Cheers Trond -- 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
