Introduction of "hostconsole" group requirement for bmcweb SOL regresses LDAP (and other remote authentication) usecases

[Paul Fertser]

Hello,

Moving the discussion here from closed code review comments for the
commit that introduced the regression[0].

Ed, I hope this is the right medium to discuss issues like that and
I'm including webui and phosphor-user-manager maintainers now.

I hope that interested parties will share the information and ideas
needed to allow LDAP-authenticated users to use SOL again.

> > looks like something that breaks compatibiliity with existing
> > installs way too much.
>
> What does "installs" mean in this context? We have an API, so far
> as I understand the API backward compatibility support has been
> maintained.

This patch seems to be written under assumption that a single user
can belong to several groups (which is normal for POSIX
systems). Compare these two cases:
```
# busctl call xyz.openbmc_project.User.Manager
/xyz/openbmc_project/user xyz.openbmc_project.User.Manager
GetUserInfo s root
a{sv} 6 "RemoteUser" b false "UserEnabled" b true "UserGroups" as 5
"hostconsole" "ipmi" "redfish" "ssh" "web"
"UserLockedForFailedAttempt" b false "UserPasswordExpired" b false
"UserPrivilege" s "priv-admin"
```
and
```
# busctl call xyz.openbmc_project.User.Manager
/xyz/openbmc_project/user xyz.openbmc_project.User.Manager
GetUserInfo s ldap_sync
a{sv} 2 "RemoteUser" b true "UserPrivilege" s "priv-admin"
```

for remote users `phosphor-user-manager` doesn't even report the
list of `UserGroups` as it has no facilities to obtain that. And
even if it did, that would require changes to the database serving
the user data. That's what I mean by existing installs, the LDAP
databases customers already have in production, plus existing
working BMC configuration.

So with this new code the old LDAP configuration can not allow SOL
anymore. Unless we fake `UserGroups` for `priv-admin` and the
rest. Is that what you suggest?

> > RHEL or Windows Server
>
> I would say the majority of OpenBMC installs aren't running either
> of these, so I'm not sure where the comparison comes from

Hm, I thought those are the most popular operating systems running
on server machines these days. What's the majority then, ESXi? But
that seems unlikely since OpenBMC was feeding it IPMI sensor names
it couldn't understand for many years and nobody complained. Is ESXi
offering more control over serial than KVM by default? So what the
majority of OpenBMC installs are running on host CPUs?

> All of this feedback it great, but you haven't really stated what
> you'd like to see happen here.

Hah, guess not so great if my point is still not clear, sorry about
that, not sure how we have this impedance mismatch again and again.

I'd like Ninad Palsule, who was behind this code creation and
submission (or anyone else who knows what the deal is about), to
provide clear rationale and explanation for this feature so that the
regression could be fixed in a meaningful way without regressing
their feature or compromising their goals. But for that we need to
understand their goals first. In your earlier comment you said "I'm
not sure what the point is of this patch then, which I thought was
to be able to dish out host console access separate from user role,
but at least this retains the current behavior." so it looks like
the intent behind this patch is not so clear and needs
clarifications.

I'd like to see the way forward with fixing the regression with
remotely authenticated users. Be it by reverting this patch or by
fixing phosphor-user-manager (I do not see a practical way other
than faking groups for remote users) or other ideas that do not
cross my mind. I think whomever introduced the regression should be
at least trying to help with that. I referred to them by "those
people" when I asked for the threat model they're working with (not
you, it's not you who introduced and advocated this functionality).

> > even worse, the web interface terminates the session on attempt
> > as it gets 401 reply
>
> I just looked, and I'm not sure how this could happen in the
> code.  I would expect a 403 forbidden from here:
>
> https://github.com/openbmc/bmcweb/blob/0bdda665a3589924e1f5a51d7ff8633c6544ffa1/include/dbus_privileges.hpp#L94
>
> Presumably that's not what you're seeing.

Indeed, I'm not seeing exactly that. With a version few months old I
was getting 401 as an unfortunate combination of bmcweb segfaulting
(presumably due to some lifetime object issues) trying to make a
reply to the request of Upgrading to websocket when user is not
allowed to that and answering 401 after restarting on some other
query. But since it's not current HEAD that's not relevant much.

Current version shows me `NS_ERROR_NET_RESET` when Firefox tries to
`GET wss://172.41.1.250/console/default` on behalf of an LDAP user
mapped to Administrator. Which is kind of OK (better than 401) but
still is a regression.


[0] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/61580
-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com