[ovs-dev] Read only versions of the *ctl binaries

Ryan Moats rmoats at us.ibm.com
Fri Jul 29 22:35:31 UTC 2016


Ben Pfaff <blp at ovn.org> wrote on 07/29/2016 05:27:29 PM:

> From: Ben Pfaff <blp at ovn.org>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: dev at openvswitch.org
> Date: 07/29/2016 05:27 PM
> Subject: Re: [ovs-dev] Read only versions of the *ctl binaries
>
> On Fri, Jul 29, 2016 at 04:11:00PM -0500, Ryan Moats wrote:
> >
> > We just received a new operational requirement that we have
> > to restrict access to all binaries that provide RW access to
> > infrastructure components, but yet still have the ability to
> > read current state from the infrastructure.
> >
> > For OVN/OVS, this means we won't be able to use the following
> > binaries in our production environment to read current state:
> > ovs-vsctl, ovs-dpctl, ovs-ofctl, ovs-appctl, ovn-nbctl, and
> > ovn-sbctl.
> >
> > I'm thinking of meeting this by creating new binaries
> > ovs-vsread, ovs-dpread, ovs-ofread, ovs-appread, ovn-nbread,
> > and ovn-sbread that would include the show, list, and search
> > commands from their RW brethren, but omit the various add
> > and del commands.
> >
> > Before I start crafting code, I wanted to see if folks can
> > think of a simpler way of meeting this new requirement...
>
> You could hard-code the 'dry_run' variable to true.
>

Yes, that will certainly be quicker, and I can couple that with
some Makefile magic to allow the same source code to produce
both the *ctl and *read binaries (which lowers future
maintenance costs too)...

The $64K question for the community is this idea acceptable?
The tl;dr; is that I'd rather not carry this type of change
around as a local patch, but I will if I have to...




More information about the dev mailing list