Skip to content

Raise the session privilege on demand: run at User, raise on D4h up to what the account allows #194

Closed

Description

@bertysentry

Why: since #192, sensors() reads the sensors of other controllers than the BMC (power supplies, fans, RAID adapter, NIC, Intel ME) through the BMC with Send Message, which needs the Operator privilege (IPMI 2.0 table G-1, note 2). The lab BMCs differ:

BMC Send Message to another controller
HPE iLO 5 allowed at User
AMI-based GIGABYTE (mgt-dev-nvidia-01) D4h at User and at Operator, allowed at Administrator only

IpmiClient runs at the level the builder sets, User by default, which is also what the MetricsHub IPMI extension uses (it has no privilege setting). On a strict BMC these sensors therefore come back without a reading, with D4h in problem(). Asking users for an Operator or Administrator account everywhere would break least privilege for the BMCs that do not need it.

Proposal: an automatic mode that runs at User and raises the session only when a command needs more, up to what the account allows. IPMI has no command that tells a User-level session its own ceiling (Get User Access needs a higher level), so:

  1. Opt-in with IpmiClient.Builder.privilege(PrivilegeLevel.MaximumAvailable), which the builder refuses today. privilege(User/Operator/Administrator) keeps its current meaning.
  2. At login, request the highest level: Open Session and RAKP Message 1 with role 0h, "highest level matching proposed algorithms" (section 13.17). The BMC caps the session at the account's limit and the cipher suite's limit.
  3. Right after login, set the session to User explicitly (Set Session Privilege Level 2h). Low-level sessions stay at the User privilege on iDRAC, iLO 5, XCC and Cisco IMC: openSession() never sends Set Session Privilege Level #165 found that 7 of 14 lab BMCs (IMM, iDRAC 6, iRMC, GIGABYTE, Supermicro) start a session at the requested maximum instead of User (section 22.18); without this step they would run as Administrator.
  4. On D4h, raise with Set Session Privilege Level to Operator (3h), then to Administrator (4h), and resend the refused command once. A D4h means the command was not executed, so the resend is safe even for the control commands. 80h (level not available for this user) or 81h (exceeds the channel or user limit) on the raise is the ceiling: remember it for the session and return the D4h as today.
  5. No loop on a revoked session: a session the BMC revoked answers D4h to everything, Set Session Privilege Level included (HP iLO 4 answers Get SDR with InsufficientPrivilege (D4h) intermittently and the whole walk fails #146). A raise that fails with anything but 80h/81h must not be retried.

Validation: live on the lab before merging. Check role 0h at login on every vendor (some BMCs may refuse it or cap it oddly, and the cipher suite privilege limits differ), the explicit drop to User, and the raise on the GIGABYTE Send Message D4h. Unit tests with FakeRmcpPlusBmc (privilege per command, 80h/81h refusals).

Then: the MetricsHub IPMI extension (IpmiRequestExecutor.newClient()) can use this mode by default, and ipmicli could take -L auto. Document the mode in configuration.md (privilege level), sensors.md (sensor owners), cli.md and upgrading.md.

Activity

  1. self-assigned this
    on Oct 17, 2026
  2. added a commit that references this issue on Oct 17, 2026
    968db1e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions