[Drbd-dev] drbd_nl.c:drbd_adm_prepare() indexes drbd_genl_ops[] by cmd number

[Lars Ellenberg]

On Tue, Jun 04, 2019 at 11:41:58AM +0200, Lars Ellenberg wrote:
> On Tue, Jun 04, 2019 at 02:18:02AM -0600, David Butterfield wrote:
> > On 6/3/19 11:43 PM, Lars Ellenberg wrote:
> > > Think again: how is family->ops inexed?
> > 
> > If you mean the genl_family, its ops are kept on a list, which is searched using genl_get_cmd().
> > Constructed as a list, it doesn't even (necessarily) have an an underlying array one might be tempted to index.
> > 
> > > How is drbd_genl_ops indexed?
> > 
> > It is an array, but it isn't indexed by command number,
> 
> Why, yes it it.
> Because it is constructed that way.
> Uhm. Wait. It used to at some point.
> But ... not so anymore.
> I can swear it used to be
> [op_name] = {
> }
> 
> in that "magic" header...

> Okay.
> 
> Either we fix it in the magic header to construct an array
> that has holes in it, but can then be indexed by [cmd],
> as I think it was meant to be, and used to be
> (though I may be misremembering).

That won't work (anymore),
because that would be rejected,
we would not be able to register that 

So we are back to this:

> Or we add an additional iteration to find the correct flags.

Or our own "bit field" to flag "privileged" operations.

Or we decide that "CAP_NET_ADMIN"
is sufficient to (re)configure DRBD.
But I don't think so.

-- 
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT