And this definition would be used if we are not using tables for users and filters?

As with tables we would not have JSON objects for user and role.
Alexey Botchkov <holyfoot@mariadb.com> schrieb am Mi. 2. Jan. 2019 um 09:33:
Hi, Ralf, Sergei!

Here below you can see the proposed syntax of filter expressions
for the Audit Plugin.
Similarly to what we see in MySQL, firstly the 'filter'-s are
defined then they are assigned to 'user'-s and 'role'-s.
Role's filters prevail over user's.


Toplevel structure is an JSON object with 3 optional keys:
"filters" - an array of 'filter' definitions
"users" - filters assigned to users.
'roles' - filters assigned to roles.

Looks like this:

{
"filters": [
  {
   "name" : "all",
   "def"  : {filter_definition}
  },
  {
    "name" : "connect_events",
    "def"  : {filter_definition}
  }
],
"users" :
[
  {
    "user" : "root@%",
    "filter" : "connect_events"
  },
  {
    "user" : "hf@%.ru",
    "filter" : "all"
  },
],
"roles" :
[
  {
    "role" : "sales",
    "filter" : "all"
  }
]
}

User names syntax is same as the used in server.
When looking the 'users' for filter we scan the array and use the first matching
'user' and use it's filter. (don't look for other possible matches)
'role'-s support no wildcards, so are simpler to match.


filter_definition:  - and array of definitions
filter_array_item [,filter_array_item ...]

filter_array_item:
filter_name |
        simple_filter

simple_filter:
{
  "do_log" : true|false,  - an optional key. Supposed to be TRUE if not specified.
  "event_type : [CONNECT, QUERY, TABLE],
  "details" :
  {
    "connect_type" : ["CONNECT, DISCONNECT, CHANGE_USER, SET_ROLE],
    "query_type" : [DDL, DML, DCL, SELECT, INSERT ...],
    "table_type" : [READ, WRITE],
    "query_tables" : ["db.table", ...],
    "table_tables" : ["db.table", ...]
  }
}

So examining an event we have the array of simple_filters to
check. If the event matches the simple_filter, we act as the 'do_log"
tells - write it to log or stop looking for match.
If no matches were found, we don't log the event.

The example of the filter definition:
{
  filter_name: "log_ddl_dcl",
  filter_def:
  {
    "event_type": "QUERY",
    "details": { "query_type": ["DDL", "DCL"] }
  }
}

{
  filter_name: "log_queries_except_test_db",
  filter_def:
  [
    {
      "do_log": FALSE,
      "event_type": "QUERY",
      "details": { "query_tables": "test.*" }
    },
    {
      "event_type": "QUERY"
    ]
  ]
}



That's basically it.
What would be your opinion? :)

Regards
HF

--

Ralf Gebhardt, Product Manager

MariaDB Corporation Ab | http://www.mariadb.com | m: +49 152-564-823-67

MARIADB OPENWORKS

February 25-27, 2019 · NYC · Register Now

mariadb.com/openworks