Currently openipmi expects that the privilege level in the open session response equals the privilege which was requested. This is wrong, because it is legal to request a lower privilege level than allowed for a user:
According to IPMI v2.0 spec the RCMP+ Open Session Response contains the _maximum_ privilege Level allowed for a session. Additionally there seems to be a bug in the HP ILO3 IPMI implementation where the maximum privilege level returned in the response is "admin" even if the user is only allowed to login with privilege "operator". Both bugs together prevent the ipmilan stonith agent to work with ILO3 and fence with priv="operator". This patch fixes the behavior of openIPMI and allows the "session open" repsonse message to contain an higher privilege level than requested. With this patch fencing with "priv=operator" works correctly. Signed-off-by: Arnd Hannemann <a...@arndnet.de> --- lib/ipmi_lan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/ipmi_lan.c b/lib/ipmi_lan.c index c55445e..095f133 100644 --- a/lib/ipmi_lan.c +++ b/lib/ipmi_lan.c @@ -4530,7 +4530,7 @@ got_rmcpp_open_session_rsp(ipmi_con_t *ipmi, ipmi_msgi_t *rspi) lan = (lan_data_t *) ipmi->con_data; privilege = msg->data[2] & 0xf; - if (privilege != lan->cparm.privilege) { + if (privilege < lan->cparm.privilege) { ipmi_log(IPMI_LOG_ERR_INFO, "%sipmi_lan.c(got_rmcpp_open_session_rsp): " "Expected privilege %d, got %d", -- 1.7.9.5 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer