Re: on-audit filtering via named pipe?

John Hardin wrote: > on-audit only allows audit filtering by action (e.g. ACTB) and not by > which table is involved. This makes it painful to use the native audit > utility when you're only interested in auditing activity on a small > handful of tables. Agreed. That is why we are working on providing a better mechanism for Panther - one that provides selective row-level auditing. > I was wondering (haven't actually tried anything yet) if it would be > possible to tell on-audit to write its audit logs to a named pipe that's > feeding through grep? That way only the activities against the table of > interest would get saved to the audit log file. No. There used to be o/s-specific support for writing to an o/s-specific audit logging mechanism. There were a variety of reasons why that was disabled, and the only currently supported mechanism is writing to files. We have not provided a mechanism to filter data as it goes to the files. > I suspect this isn't possible, as the log file size management stuff and > a comment I saw that "keeping an empty log file will prevent on-audit > from reusing the file name" suggest that on-audit is too smart, would > see the named pipe, and would pick a different filename to write to. Exactly. It also means you cannot write audit logs directly to a tape; the tape device exists and IDS would avoid using it. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0229 -- http://dbi.perl.org/ publictimestamp.org/ptb/PTB-7125 ripemd160 2009-09-12 15:00:04 C50DF3A3B0F6123019664C27751AC9F21D64C204

"Jonathan Leffler" <jleffler@earthlink.net> wrote: > John Hardin wrote: >> on-audit only allows audit filtering by action (e.g. ACTB) and not by >> which table is involved. This makes it painful to use the native audit >> utility when you're only interested in auditing activity on a small >> handful of tables. > > Agreed. That is why we are working on providing a better mechanism for > Panther - one that provides selective row-level auditing. Looking forward to it. One comment: it should not be necessary to know the tabid in order to filter. The filter config should be able to specify db:own:tabname or (better) just db:tabname and have onaudit look up the tabid for internal use. One other thing that I'm sure would be of interest is logging the queries themselves. I know that would be very resource-intensive, so I would suggest that it only be done by (configurable) type (SELECT, UPDATE, subquery, etc.), for specific (configurable) users, and/or only be done if a query affects a (configurable) table or table:column - for example, it would be nice to be able to log the SQL text of all SELECT queries that retrieve Credit_Card.Card_Number... -- John Hardin KA7OHZ Senior Applications Developer, BI Specialist EPICOR Retail web: http://www.epicor.com voice: (425) 245-1800 fax: (425) 670-1810 email: <jhardin@epicor.com> 20818 44th Ave. W., Suite 270 Lynnwood, WA 98036 USA Worldwide Headquarters 18200 Von Karman, Suite 1000, Irvine CA 92612 USA ------------------------------------------------------------------------ The first time I saw a bagpipe, I thought the player was torturing an octopus. I was amazed they could scream so loudly. ------------------------------------------------------------------------

"John Hardin" <jhardin@epicor.com> wrote in message news:h8ln1v$faf$1@adenine.netfront.net... > "Jonathan Leffler" <jleffler@earthlink.net> wrote: >> John Hardin wrote: >>> on-audit only allows audit filtering by action (e.g. ACTB) and not by >>> which table is involved. This makes it painful to use the native audit >>> utility when you're only interested in auditing activity on a small >>> handful of tables. >> >> Agreed. That is why we are working on providing a better mechanism for >> Panther - one that provides selective row-level auditing. > > Looking forward to it. > > One comment: it should not be necessary to know the tabid in order to > filter. The filter config should be able to specify db:own:tabname or > (better) just db:tabname and have onaudit look up the tabid for internal > use. > > One other thing that I'm sure would be of interest is logging the queries > themselves. I know that would be very resource-intensive, so I would > suggest that it only be done by (configurable) type (SELECT, UPDATE, > subquery, etc.), for specific (configurable) users, and/or only be done if > a query affects a (configurable) table or table:column - for example, it > would be nice to be able to log the SQL text of all SELECT queries that > retrieve Credit_Card.Card_Number... I am already considering doing something similar in IDS 11 using a simple 4GL program polling the "syssqltrace" table every few seconds with SQLTRACE enabled.