This raises an issue that I've often wondered how other people handle:
If a DBA (or anyone else) has shell access to the machine, then they can simply edit the
log to cover their tracks. How do you prevent this scenario?
Regards,
Gavin Towey
-----Original Message-----
From: Rick James [mailto:rjames@stripped]
Sent: Wednesday, November 11, 2009 11:12 AM
To: Davi.Arnaut@stripped; Paolo Lunazzi
Cc: internals@stripped
Subject: RE: access log
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
>
>
--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?unsub=1
The information contained in this transmission may contain privileged and confidential
information. It is intended only for the use of the person(s) named above. If you are not
the intended recipient, you are hereby notified that any review, dissemination,
distribution or duplication of this communication is strictly prohibited. If you are not
the intended recipient, please contact the sender by reply email and destroy all copies
of the original message.
