On Fri, May 12, 2017 at 03:07:23PM -0400, Lance Richardson wrote: > Add suport for ovsdb RBAC (role-based access control). This includes: > > - Support for "RBAC_Role" table. A db schema containing a table > by this name will enable role-based access controls using > this table for RBAC role configuration. > > The "RBAC_Role" table has one row per role, with each row having a > "name" column (role name) and a "permissions" column (map of > table name to UUID of row in separate permission table.) The > permission table has one row per access control configuration, > with the following columns: > "name" - name of table to which this row applies > "authorization" - set of column names and column:key pairs > to be compared against client ID to > determine authorization status > "insert_delete" - boolean, true if insertions and > authorized deletions are allowed. > "update" - Set of columns and column:key pairs for > which authorized updates are allowed. > - Support for a new "role" column in the remote configuration > table. > - Logic for applying the RBAC role and permission tables, in > combination with session role from the remote connection table > and client id, to determine whether operations modifying database > contents should be permitted. > - Support for specifying RBAC role string as a command-line option > to ovsdb-tool (Ben Pfaff). > > Signed-off-by: Lance Richardson <[email protected]> > --- > > Note to Ben: with your incremental patch, I think your co-authored-by and > signed-off-by are probably needed... if you agree, please add.
OK, fair enough. Feel free to add a Co-authored-by; my Signed-off-by will likely be naturally added, since I'm likely to commit this myself in the end. > v2: > - Folded in incremental patch from Ben Pfaff with style cleanup, a > bug fix, and addition of --rbac-role option to ovsdb-tool. > - Documented differences with respect to RFC 7074 in ovsdb-server(1). One oddity I noticed is that ovsdb_rbac_insert() takes an 'id' but does not look at it (other than to check that it is nonnull). This is a little surprising from the documentation, but maybe it makes sense. I think that the overall policy is that a client that is allowed to insert a row can insert any row at all, even rows that it couldn't modify or delete. Is that the idea? Is it reasonable? An alternative policy, which might be more consistent, might be to check that the initial data in the row that is being inserted conforms to the policy for a row that a client is allowed to modify or delete. What do you think? Thanks, Ben. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
