maria-developers team mailing list archive

[Ralf Gebhardt <ralf.gebhardt@xxxxxxxxxxx>]

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@xxxxxxxxxxx> 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 <https://mariadb.com/conference/>