To be a useful audit log, it would need to record any alterations to the
access control. That is, GRANT/REVOKE, plus any manual changes to the
tables in 'mysql'.
I would vote for even the simple login-log. I have had need to get a
complete list of who (what applications) are logging in from what
machines. Polling SHOW PROCESSLIST is hit or miss. More
specifically...
To see whether a login is used any more. (Alternatively, a record of
last login time would suffice.)
To see which colocations are hitting which slaves. (Generally
intra-colo connections are preferred over cross-colo.)
Rick James
MySQL Geeks - Consulting & Review
> -----Original Message-----
> From: Davi.Arnaut@stripped [mailto:Davi.Arnaut@stripped]
> Sent: Wednesday, November 11, 2009 10:49 AM
> To: Paolo Lunazzi
> Cc: internals@stripped
> Subject: Re: access log
>
> On 11/11/09 3:25 PM, Paolo Lunazzi wrote:
> > On Wed, Nov 11, 2009 at 4:22 PM, Davi
> Arnaut<Davi.Arnaut@stripped> wrote:
> >>
> >> On 11/11/09 9:08 AM, Paolo Lunazzi wrote:
> >>>
> >>> Hi everybody,
> >>> I'm starting to look inside MySQL Internals because I
> need to write a
> >>> little patch to log users access into db.
> >>
> >> The server already has a few logs:
> >>
> >> http://dev.mysql.com/doc/refman/5.1/en/server-logs.html
> >>
> >> What do you have in mind specifically?
> >
> > General Query Log writes information when clients connect or
> > disconnect and it logs each SQL statement received from
> clients too. I
> > want to be able to choose to log all or only information
> about access
> > to db ( timestamp, user, host, db, ...) and I want to be able to do
> > that only for some user groups.
>
> Indeed, we don't have this kind of finer grained logging.
>
> > The idea comes from an Italian law that will be in force
> this December
> > that establish to log information about db administrators access. At
> > the moment it's possibly to log all or nothing, I think that a
> > management more customizable of this kind of logging might be useful
> > even in other contexts.
>
> OK, in this case you have two options. You can do
> post-filtering on the
> log tables -- for example, by having a periodic event that
> scans the log
> table and filters the data to another table.
>
> Another option is to implement a new log handler -- if you
> look at file
> sql/log.h, there is a abstract Log_event_handler class that you can
> extend to implement a new log target (eg: Log_to_csv_event_handler).
>
> You will probably be interested in the log_general method,
> where you can
> access various information about the current user session (THD). For
> some initial fun, you could look around sql/log.cc and play with the
> log_general method of the class Log_to_csv_event_handler or
> Log_to_file_event_handler. If you know your way around C++,
> shouldn't be
> difficult.
>
> --
> Davi Arnaut
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:
> http://lists.mysql.com/internals?unsub=1
>
>
