← Back to team overview

linux-traipu team mailing list archive

[Bug 887346] Re: Authorization API doesn't differentiate reads from writes, etc...

 

Bug arises from work on documenting policy plugins. See
https://lists.launchpad.net/drizzle-discuss/msg08365.html for the
background.

** Tags added: authorization docs policy

-- 
You received this bug notification because you are a member of UBUNTU -
AL - BR, which is subscribed to Drizzle.
https://bugs.launchpad.net/bugs/887346

Title:
  Authorization API doesn't differentiate reads from writes, etc...

Status in A Lightweight SQL Database for Cloud Infrastructure and Web Applications:
  New

Bug description:
  Authorization API is defined in drizzled/plugin/authorization.h. It
  allows plugins to restrict access to databases, tables and processes.
  But that is all: "access" can mean anything. In particular, there is
  no way to create a user that would have read access but not write
  access.

  To be more compatible with SQL standard, the Authorization API needs
  to also support different operation types. This could be done by
  defining an enum type that lists all the possible privilege types,
  that is then passed as an additional argument to the currently
  existing functions. The enum should at least contain something simple
  like read and write, but might ultimately support a wide range of fine
  grained privileges as we are used to from, say, MySQL:
  http://dev.mysql.com/doc/refman/5.1/en/grant.html#grant-privileges

  For backward compatibility, the currently existing functions may of
  course stay. It would allow policy plugins to just implement a simple
  "all or nothing" access policy without having to deal with this new
  argument at all.

  Example of old API method:

    virtual bool restrictTable(const drizzled::identifier::User&
  user_ctx, const drizzled::identifier::Table& table);

  Example of new API method:

    virtual bool restrictTable(const drizzled::identifier::User&
  user_ctx, const drizzled::identifier::Table& table, const privilege_t
  operation);

  Then of course all drizzled code has to be changed to actually use
  this new method and specify the operation being performed. The new
  method would then first call the old operation-less method so that
  plugins that only use the simple API are called first. (If access is
  restricted, then it's restricted, no need to continue after that.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/drizzle/+bug/887346/+subscriptions


References