Re: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege than requested
On Thu, 2012-07-26 at 06:41 -0700, Andy Cress wrote:
Certainly a needed patch, but why do this check at all (other than FYI)?
Even if the privilege is detected wrong here, it should not abort, but
proceed.
If the privilege is wrong, the target firmware will reject it.
I do a similar check/error out in FreeIPMI. I believe it's the right
thing to do to error out at the authentication phase and tell the user
they can't connect at the requested privilege level. Otherwise, random
IPMI commands will just fail with privilege level not sufficient later
on.
Al
Andy
-Original Message-
From: Arnd Hannemann [mailto:a...@arndnet.de]
Sent: Thursday, July 26, 2012 7:16 AM
To: openipmi-developer@lists.sourceforge.net
Subject: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilege
thanrequested
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,
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
--
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
Re: [Openipmi-developer] [PATCH] ipmi_lan: Accept higher privilegethan requested
On Thu, 2012-07-26 at 07:21 -0700, Andy Cress wrote: Al, This is in the open session logic (once). If the session requires a higher privilege level, it should request a higher privilege level. Either the firmware will allow the session open with the requested privilege or it won't. I don't understand your reference to 'random IPMI commands'. Ohhh, you're right. It would be caught at the set session privilege level stage later on, I forgot about that. My random IPMI commands was in reference to the actual IPMI commands sent out later in the session, like Get Device ID or Get Sensor Reading or Get SEL Info. I'm mixing different issues in my head. Al Is there really a use case where you would not want it to proceed, given that there is a use case (ILO3 bug) where allowing it to go through is better? Andy Even if the privilege is detected wrong here, it should not abort, but proceed. If the privilege is wrong, the target firmware will reject it. I do a similar check/error out in FreeIPMI. I believe it's the right thing to do to error out at the authentication phase and tell the user they can't connect at the requested privilege level. Otherwise, random IPMI commands will just fail with privilege level not sufficient later on. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory -- 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
Re: [Openipmi-developer] OpenIPMI sensor's names/sensor's Id with strange suffix 1 (tested on Sun x64 servers)
Hey Corey,
Any opinions on this from anyone else? IMHO, this is a poor design in
the spec, and it's silly for anyone to put a 1 in this share count field.
I concur that it's silly. I have this recollection that I too
implemented share_count != 0, then later changed it to share_count
1 in FreeIPMI when I saw that's how it was implemented in motherboards.
Al
On Fri, 2010-05-28 at 10:49 -0700, Corey Minyard wrote:
Resend, I sent from the wrong account.
Well, this is certainly a gray area in the spec. The SDR in question is:
SDR
Record ID: 30
Type: 2
Version: 1.5
Data: 0x20 0x00 0x64 0x0a 0x00 0x67 0x40 0x25
0x08 0x03 0x00 0x00 0x00 0x03 0x00 0xc0
0x00 0x00 0x01 0x81 0x00 0x00 0x00 0x00
0x00 0x00 0xc9 0x50 0x53 0x30 0x2f 0x50
0x52 0x53 0x4e 0x54
Bytes 18 and 19 are the ones in question, these correspond to byte 24
and 25 of the SDR type 02h Compact Sensor Record. Since the share
count is non-zero, OpenIPMI assumes that it is doing sensor sharing and
numbers them as specified in the spec and the other bits in those
bytes. Thus it appends the 1.
You can fix this problem by changing lib/sensor.c, line 1441 from:
if (share_count) {
to
if (share_count 1) {
Any opinions on this from anyone else? IMHO, this is a poor design in
the spec, and it's silly for anyone to put a 1 in this share count field.
-corey
Alex Deiter wrote:
Hi Corey,
Also i uploaded output from command:
mc sdrs test(0.20) main
into http://*deiter.net.ru/mc_sdr.txt
Thanks a lot!
2010/5/28 Corey Minyard cminy...@mvista.com:
Can you do:
mc sdrs test(0.20) main
and send me the output?
-corey
Alex Deiter wrote:
Dear Corey,
I found strange fact - on Sun x64 servers some sensors with discrete
type has incorrect names (it different then output from ILOM,
ipmitool, snmp etc).
Name for some (not all) *PRSNT sensors has suffix 1:
$ openipmish
domain open test lan -U root -P passwd -L user 10.1.1.1
...
Event
Object Type: Sensor
== Name: test(10.0).PS0/PRSNT1
Operation: Add
...
sensor list
Entity
Name: test(10.0)
Sensors
Name: test(10.0).PS0/OUT_POWER
Name: test(10.0).PS0/IN_POWER
Name: test(10.0).PS0/I_OUT
Name: test(10.0).PS0/V_OUT
Name: test(10.0).PS0/I_IN
Name: test(10.0).PS0/V_IN
Name: test(10.0).PS0/TEMP_FAULT
Name: test(10.0).PS0/FAN_FAULT
Name: test(10.0).PS0/VOLT_FAULT
Name: test(10.0).PS0/CUR_FAULT
Name: test(10.0).PS0/PWROK
Name: test(10.0).PS0/VINOK
==Name: test(10.0).PS0/PRSNT1
Name: test(10.0).MB/V_+1V4
Name: test(10.0).MB/V_+3V3STBY
Name: test(10.0).MB/V_+5V
Name: test(10.0).MB/V_+3V3
Name: test(10.0).MB/V_+1V5
sensor info test(10.0).PS0/PRSNT1
Sensor
Name: test(10.0).PS0/PRSNT1
LUN: 0
Number: 100
Event Reading Type: 8
Event Reading Type Name: discrete_device_presense
Type: 37
Type Name: entity_presense
Event Support: per state
Init Scanning: true
Init Events: true
Init Thresholds: false
Init Hysteresis: false
Init Type: true
Init Power Up Events: true
Init Power Up Scanning: true
Ignore If No Entity: false
Auto Rearm: true
OEM1: 0
Id: PS0/PRSNT1
Event
Offset: 0
Name: device removed/absent
Supports: assertion
Event
Offset: 1
Name: device inserted/present
Supports: assertion
output from ipmitool sensor list:
...
PS0/PRSNT| 0x2| discrete | 0x0200| na| na
| na| na| na| na
...
output from ipmitool sensor get PS0/PRSNT:
Locating sensor record...
Sensor ID : PS0/PRSNT (0x64)
Entity ID : 10.0
Sensor Type (Discrete): Entity Presence
States Asserted : Availability State
[Device Present]
output from ILOM:
$ ssh r...@10.1.1.1
Password:
Sun(TM) Integrated Lights Out Manager
Version 3.0.6.16 r50656
Copyright 2009 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
- show /SYS/PS0/PRSNT
/SYS/PS0/PRSNT
Targets:
Properties:
type = Entity Presence
ipmi_name = PS0/PRSNT
class = Discrete Sensor
value = Present
alarm_status = cleared
snmp also show sensor names without suffix 1.
Could you please explain this behavior for OpenIPMI ?
Thanks a lot!
--
Alex Deiter
--
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://*lists.sourceforge.net/lists/listinfo/openipmi-developer
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High
