OpenBMC community telecon - 11/27 Agenda

Brad Bishop bradleyb at
Tue Dec 19 05:07:04 AEDT 2017

On Mon, 2017-12-04 at 17:02 -0800, Vernon Mauery wrote:

Hi Vernon

Really appreciate you putting this together - thanks.  I do have a
couple comments/questions.

> For the discussion on user management.
> Overview:
> 1. User management is done via PAM.

Are there any aspects of user management that are done outside of PAM?
I only ask this because your writeup feels like a good start on a
README somewhere.  To that end, would it make sense to frame this from
the perspective of different actors attempting to add function?  For

 If you want to implement a service that authenticates a user:
   - do v
   - do w

 If you want to implement a service that adds users to a user database:
   - do x

 If you want to implement a service that adds users to a group:
   - do y

 If you want to implement a service that authorizes a user:
   - do z

 etc, and then the IPMI specifics would just be adhering to this

I could have these bullet points all wrong.  This was just meant as a
straw-man for a more general document that can guide people looking to
add this type of function later.

> 2. If IPMI is being used, PAM loads the password module.
>    a. intercepts password changes and saves the password
>       for IPMI-enabled users to a file that can be read at a later
> time
>       to initiate an RMCP+ session. (encrypted or obfuscated with a 
>       per-BMC key so no passwords are written directly in flash.)
>    b. implements a method to decrypt passwords and
> provide
>       them to host-ipmi (for test password command) and net-ipmi (for
>       session initiation)
> 3. If a user is not enabled for IPMI, their password will not be
> saved
>    in the ipmi database, and thus must be reset if/when that user
> gains
>    IPMI capability.
> 4. If a user loses IPMI capability, their password is reset to force
> a
>    password change so their password is secure again.

I'm not understanding why this is needed.  Couldn't we simply remove
the password entry from the IPMI backend when the group membership
changes?  Is this an artifact of how PAM works or do we think we need
it for a more fundamental reason?

> 5. Capabilities is done via unix groups
>    a. Groups like ipmi, webserver, redfish, ssh, sol can provide
> login 
>       or 'channel' access.

I wonder if a per-channel (or service in PAM speak?) pam_listfile
account entry can get us here.

>    b. Groups like user-manager, media, power, sensor, etc., can
> provide
>       fine-grained access for various capabilities. Providers of 
>       capabilities should check to see that accessors (users) have
> the 
>       required permission.

pam_listfile might work here too, only this would global across all PAM

> 6. Admin-defined 'super-groups'
>    a. Provide a set of pre-defined groups of capabilities that can be
>       assigned to users: Admin, User, Operator or similar that each
> have
>       groups associated with them.

Do we intend to also allow the contained subgroups to be
changed/configured for the on the BMC dynamically?  For example could
you remove the 'sensor' group from the Operator group (assuming that by
default sensor group is included in the Operator group).

>    b. Changes to groups via APIs can make sure that if a user is 
>       assigned to a 'super-group' will stay assigned to the sub-
> groups
>    c. Changes made to users via manual commands may override API
> groups

This all seemed pretty straightforward until I got to #6.  It seems
like it is definitely required but I'm wondering if it could be staged
in later somehow?

> Methods:

Do we need similar APIs for groups?

>     1. CREATE_USER
>         Privilege-required: USER-MANAGER
>         Args:
>             UserName - STRING (16 bytes only - else role change to
> IPMI can't be done)
>             Password - Byte Array (Max of 20 bytes if IPMID is
> chosen. For
>                        others can send more bytes, but change role to
> IPMI will
>                        request password again under 20 bytes)
>             Roles - STRING with comma separated
>         Return:
>     2. DELETE_USER
>         Privilege-required: USER-MANAGER
>         Args:
>             UserName - STRING
>         Return:

Can we use the xyz.openbmc_project.Object.Delete interface for this? 
The thinking was that a common Delete interface might make DBus<->UI
implementations easier.  This is the same motivation behind asking for
the org.freedesktop interfaces below.

>         Privilege-required: USER-MANAGER
>         Args:
>             UserName - STRING
>             New Password (if changed) - Byte Array
>             New Role (if changed) - Array of STRING
>         Return:

I thought the intent was to strictly use PAM for this.  In what
scenario do we need a DBus API for this?

>         Privilege-required: Any Valid user
>         Args:
>             New Password - Byte Array
>         Return:

Same question as #3.

>         Privilege-required: USER-MANAGER
>         Args:
>             NULL
>         Return:
>             Array of:
>                 USER_NAME (String)
>                 ROLES (String)

Could we use org.freedesktop.DBus.ObjectManager.GetManagedObjects for

> Signals:
>         Args:
>             UserName of updated user
>             UpdateType:
>                 Role changed / User Deleted / User created / Password

Could we use org.freedesktop.DBus.Properties.PropertiesChanged here?

> Changed etc.     

More information about the openbmc mailing list