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

[Ben Pfaff]

On Fri, Jul 29, 2016 at 05:35:31PM -0500, Ryan Moats wrote:
> 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...

I'm not yet convinced that this is useful.  Is it a valuable feature or
a bureaucratic requirement?