Re: Discussion on openbmc issue #430

[tomjose <tomjose@linux.vnet.ibm.com>]

Thanks Patrick for your feedack. I have mentioned my responses inline.

On Friday 12 August 2016 07:47 PM, Patrick Williams wrote:
> Tom,
>
> Thanks for sending this out to the broader community.
>
> Few comments below...
>
> On Fri, Aug 12, 2016 at 07:26:24PM +0530, tomjose wrote:
>> *Registering Callback Routines:-*
>> -----------------------------------------------
>> 1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)
> I would prefer we have a new directory '/usr/lib/phosphor-net-ipmid' for
> the RMCP libraries.  We can create symlinks between the two repos as
> appropriate.
>
> The reason for this is two-fold:
>     1) I suspect there will be some of the OEM commands that we will want
>        to expose in-band only.
>     2) There are commands that may want similarly excluded from the
>        in-band path due to security concerns (even though we have the
>        white-list support).
>
> We might want to have a '/usr/lib/ipmid-providers' as the default
> install location for all providers and then symlink into both
> phosphor-net and phosphor-host as appropriate.
In the proposal, i had mentioned there is a provision to add channel 
restrictions to each command.
There are 3 variants available: execute on any channel, execute in-band 
only and execute on lan only.
The channel restriction would be evaluated before each command is executed.
I hope this would meet the same requirements.

>
>> 2) Scan for libraries that end with .so
> Keep in mind you'll need to deal with versioned .so's as well.  We had
> to add that support to host-ipmid recently.

Sure would take this into account while implementing.
>
>> 3) Do a dlopen that would register the handlers for the callback routines.
>> The data that is currently registered for each command: Net Function,
>> Command and Functor.
> There are a few providers that register for dbus callbacks so they can
> monitor signals.  We'll need to discuss a little more I think on what
> the expectation is here.  Maybe the way we are doing dbus callbacks
> isn't appropriate to begin with, or maybe the callbacks are for host
> alerts and not needed in the network path?
>
>> *SessionLess Commands :-
>> *-------------------------------------*
>> *
>> This would mention whether the command can be executed without a
>> session. For example
>> Get Channel Capabilities can be executed without a session.
> How do we identify session-less commands?  Should this be an enhancement
> to the registration API?
The session less commands are mentioned in the IPMI specification.
Examples are Get Channel Authentication Capabilites, Activate Session 
command etc.

>
>> *Minimum Privilege Required to Execute the command :-
>> *---------------------------------------------------------------------------------*
>>
>> *This field would mention the minimum privilege of the session required
>> to execute the
>> command. Before executing any command on a session, the command would be
>> executed
>> only if the command privilege level is less than or equal to session
>> privilege level.
>> The privilege levels are Administrator, Operator, User and Callback and OEM
> Are these privilege levels something intrinsic in IPMI or something you
> came up with?
>
> We plan to integrate the ipmi server into the same BMC user list as the
> REST interface.  I think we need to identify these roles and then allow
> unix-group membership to determine which commands can be ran.
>
> We have a feature to be implemented for the REST interface to define
> group membership requirements for dbus / REST calls as well.
>
> How should providers specify these?

The privilege levels attributed to each command is mentioned in the 
specification.
It is mentioned in the specification Table G-1,(Command Number 
Assignments and
Privilege Levels). The providers should provide these as registration 
parameters
when the callbacks are registered.
>