IDS 10.00.FC11 on Sun 5.10 - Informix audit issue

I am trying to diagnose why we are seeing extra audit log entries for certain remote sessions and have found the following so far: 1) Only some of the sessions from this specific remote server (same user id) generate RDRW log entries, which should not be audited due to audit mask settings. 2) The pid for the sessions did not exist on the local server at the time I checked that the sessions were still running, but on the remote server it is for the 2nd cpu vp on one of the instances there (same IDS/OS ver). 3) I double checked the other sessions for that user id/remote server, running on the local server and while there are reads occurring they are not being audited, which is what we expect. 4) The extra log entries only show up between certain hours, which again leads me to believe this is not someone changing the audit mask (as one of my co-workers suggested), but either a defect or expected behavior for these sessions due to something I am not aware of. The only reason this is an issue, is that we normally have a process to compress and then scp the audit log files to another server for storage and this broke the other day and we filled up the file system. So I need to determine the root cause, especially after my co-worker's comments to the customer (they are now worried that someone did this on purpose). Any ideas on the following: 1) Are these being started by a stored procedure ? 2) Why would these particular sessions act differently in terms of auditing? 3) Is this a known defect ? (Yes, I know we are on an unsupported version) Thanks! --e89a8f3ba41756939e04cd828469

are you able to list the audit mask settings realting to the problem ?

Karl, I am not able to copy what exists on the customer server, but the issue is with the RDRW audit event. There is a _default audit mask that includes RDRW, however in the audit mask created for the user is is excluded as in the following: onaudit -a -u userX -r _default -e ACTB,BGTX,CLDB,CMTX,DLRW,INRW,RDRW,UPRW This seems to work (based on my grep of this user id from the audit log) for most sessions coming from the remote server for this id. However, I keep seeing (no the application group has not gotten back to me yet) 3 sessions with the same PID (in all cases I have checked this is the PID for a cpu vp on the remote server) all act differently and all have "console" as the tty for the session. I have verified that the other sessions for this user id do in fact have select statements, but they are not being audited, as per the mask. I have to assume that this means that for some reason the _default mask is being used and thus RDRW is being audited. I would like to understand why (what circumstances this can happen under) this happens so that I can go back to the customer with an explanation. This may have been occurring for some time but was not noticed since the audit log files normally are moved to another server for storage every 15 minutes and that process broke last week and the local file system filled up. Yes, one solution would be to remove RDRW from the _default mask, but before I suggest that I would need buy in from the customer. Thank you. On Mon, Nov 5, 2012 at 2:33 PM, KARL OLIVER <karl.oliver@maf.govt.nz> wrote: > are you able to list the audit mask settings realting to the problem ? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8f502e0c42960804cde87a5b

I have had similar problem where i had an event in _require and excluded in the user. Reading manual it says masks are read in following order username,_default,_require,_exclude which explains why event is still be audited i think.

I'm sorry. I don't follow. My issue is that most of the sessions for that user id work as expected per the audit masks defined. However, I have 3 sessions, same pid, that always audit RDRW events unlike the other sessions for that user id from the same server. We exclude the RDRW events in the user mask and so it should hold true for that user at all times, unless there is a defect/exception I am not aware of and this is what I am looking for. Thank you. On Wed, Nov 7, 2012 at 1:57 PM, KARL OLIVER <karl.oliver@maf.govt.nz> wrote: > I have had similar problem where i had an event in _require and excluded in > the user. > Reading manual it says > masks are read in following order username,_default,_require,_exclude > which explains why event is still be audited i think. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340ba547a06e04cdfc142c