[ovs-dev] [PATCH] [RFC] ovn-controller: Experiment with restricting access to columns.

Ben Pfaff blp at ovn.org
Sat Jun 16 04:52:32 UTC 2018


On Fri, Jun 15, 2018 at 07:22:38PM -0700, Han Zhou wrote:
> On Fri, Jun 15, 2018 at 7:11 AM, Mark Michelson <mmichels at redhat.com> wrote:
> 
> > On 06/13/2018 11:29 PM, Han Zhou wrote:
> >
> >> On Wed, Jun 13, 2018 at 3:37 PM, Ben Pfaff <blp at ovn.org> wrote:
> >>
> >>>
> >>> To make ovn-controller recompute incrementally, we need accurate
> >>> dependencies for each function that reads or writes a table.  It's
> >>> currently difficult to be sure about these dependencies, and certainly
> >>> difficult to maintain them over time, because there's no way to actually
> >>> enforce them.
> >>>
> >>> This commit experiments with an approach that allows for fairly
> >>> fine-grained access control within ovn-controller to tables and columns.
> >>> It's based on generating a new version of the IDL data structures for
> >>> each
> >>> case where we want different access control.  All of these data
> >>> structures
> >>> have the same format, but the columns that a given piece of code is not
> >>> supposed to touch are renamed to discourage programmers from using them,
> >>> e.g. they're given names suffixed with "__accessdenied".  (This means
> >>> that there is no runtime overhead to the access control since it only
> >>> requires a cast to convert between the regular and restricted versions.)
> >>> In addition, when a columns is supposed to be read-only, functions for
> >>> modifying the column are not supplied.
> >>>
> >>> This commit only tries out this experiment for a single file within
> >>> ovn-controller, the BFD implementation (mostly because that's
> >>> alphabetically first, no other real reason).  It would require a little
> >>> more work to apply it everywhere, but it's probably not a huge deal.
> >>>
> >>> Comments?
> >>>
> >>> CC: Han Zhou <zhouhan at gmail.com>
> >>> Signed-off-by: Ben Pfaff <blp at ovn.org>
> >>> ---
> >>>   ovn/controller/automake.mk         |   5 +
> >>>   ovn/controller/bfd-vswitch-idl.def |  21 ++++
> >>>   ovn/controller/bfd.c               |  20 ++--
> >>>   ovn/controller/bfd.h               |   8 +-
> >>>   ovn/controller/ovn-controller.c    |  13 ++-
> >>>   ovsdb/ovsdb-idlc.in                | 223
> >>> ++++++++++++++++++++++++++++++
> >>>
> >> ++++++-
> >>
> >>>   6 files changed, 268 insertions(+), 22 deletions(-)
> >>>   create mode 100644 ovn/controller/bfd-vswitch-idl.def
> >>>
> >>>
> >> I wanted to have a quick test but it didn't pass the compile:
> >> In file included from ovn/controller/bfd.c:17:0:
> >> ovn/controller/bfd.h:19:44: fatal error: ovn/controller/bfd-vswitch-idl
> >> .h:
> >> No such file or directory
> >>
> >
> > Here's a different datapoint in the same category.
> >
> > I got a slightly different error when I tried to compile.
> > ovn/controller/bfd-vswitch-idl.h was auto-generated and everything worked
> > up until the very end:
> >
> > "The following files are in git but not the distribution:
> > ovn/controller/bfd-vswitch-idl.def"
> >
> > The make command I ran was `make sandbox SANDBOXFLAGS="--ovn"`
> >
> > I tried running `make distclean` then reconfiguring, but this didn't help.
> >
> > For comparison, Han, these are my software versions, in case that might be
> > why auto-generation worked for me but not you:
> > gcc version is 7.3.1
> > make version is 4.2.1
> > autoconf version is 2.69
> >
> > Hey Mark, thanks for sharing. I figured out that my error was due to the
> space v.s. tab in the receipt line in makefile (tab should be used):
> 
> +
> +$(ovn_controller_ovn_controller_SOURCES:.c=.$(OBJEXT)): \
> +       ovn/controller/bfd-vswitch-idl.h
> +ovn/controller/bfd-vswitch-idl.h: lib/vswitch-idl.ovsidl
> ovn/controller/bfd-vswitch-idl.def ovsdb/ovsdb-idlc.in
> +       $(AM_V_GEN)$(OVSDB_IDLC) c-idl-subset lib/vswitch-idl.ovsidl
> $(srcdir)/ovn/controller/bfd-vswitch-idl.def > $@.tmp && mv $@.tmp $@
> 
> The original patch was using tab. I should not copy/paste from browser :(
> Now I can compile without any issues, and I didn't encounter the problem
> you mentioned.

Oh, that's good news.


More information about the dev mailing list