Steve Grubb <[EMAIL PROTECTED]> writes:
> I've just released a new version of the audit daemon.
Thank you Steve. With this update, and bug fixes to my code, my
analysis program completes without reporting internal
inconsistencies. This usually means most of the bugs have been
removed.
I care
On Friday 27 July 2007 10:10:17 John D. Ramsdell wrote:
> Notice this event has two PATH records, whereas all of the many other
> open events I studied in my logs have one PATH record. It's as if the
> open system call can behave as the openat system call. I changed my
> analysis program to use t
I notice that /bin/rm no longer uses the unlink system call, but
instead uses unlinkat.
Steve Grubb <[EMAIL PROTECTED]> writes:
> But openat does give a different output:
...
> Low and behold the record changes to this:
Note that my trick of looking at the last path record for the file
name wo
Let me suggest that a library function be added to auparse that
identifies the version of the library to its clients. This is helpful
for generating good debugging messages, but also eases the task of
associating a version number with the output of a log analysis
program. Knowing the version numb
I'm probably out of my league by responding here, but some syscall
records do have more than one path. For instance,
mv file1 file2
will have a path record for both file1 and file2 ... The same type of
thing is true for cp file1 file2
Karen Wieprecht
--
Linux-audit mailing list
"Wieprecht, Karen M." <[EMAIL PROTECTED]> writes:
> I'm probably out of my league by responding here, but some syscall
> records do have more than one path.
You are correct. I would expect the rename(2) system call to have two
PATH records, and the renameat(4) call to have four. I suppose I
sho
[EMAIL PROTECTED] (John D. Ramsdell) writes:
> I carefully studied the output of my analysis program, and found one
> particularly odd line of output. I traced it back to an interesting
> audit event in the raw log (syscall 5 is the open system call):
I found the place in the source for the prog
Hi,
I was testing our rawhide kernel and I'm scrolling these errors:
WARNING: at kernel/auditsc.c:859 audit_log_execve_info() (Not tainted)
Call Trace:
[] audit_log_exit+0x5d7/0x964
[] trace_hardirqs_on+0x12e/0x151
[] audit_syscall_exit+0x9b/0x300
[] syscall_trace_leave+0x2c/0x87
[] int_ver
On Friday 27 July 2007 16:44:05 Peter Zijlstra wrote:
> On Fri, 2007-07-27 at 16:13 -0400, Steve Grubb wrote:
> > I was testing our rawhide kernel and I'm scrolling these errors:
>
> How can I reproduce this? (I once figured out how to enable execve
> auditing but have since forgotten)
I don't kno
On Fri, 2007-07-27 at 16:13 -0400, Steve Grubb wrote:
> I was testing our rawhide kernel and I'm scrolling these errors:
How can I reproduce this? (I once figured out how to enable execve
auditing but have since forgotten)
And are you doing more than enabling it? That is, does it auto-magically
On Fri, Jul 27, 2007 at 04:13:10PM -0400, Steve Grubb wrote:
> > + len = strnlen_user(p, MAX_ARG_PAGES*PAGE_SIZE);
> > + /*
> > +* We just created this mm, if we can't find the strings
> > +* we just copied into it something is _very_ wrong. Similar
> > +
On Fri, Jul 27, 2007 at 04:13:10PM -0400, Steve Grubb wrote:
> Hi,
>
> I was testing our rawhide kernel and I'm scrolling these errors:
>
> WARNING: at kernel/auditsc.c:859 audit_log_execve_info() (Not tainted)
>
> Call Trace:
> [] audit_log_exit+0x5d7/0x964
> [] trace_hardirqs_on+0x12e/0x151
On Friday 27 July 2007 17:03:59 Alexander Viro wrote:
> On Fri, Jul 27, 2007 at 04:13:10PM -0400, Steve Grubb wrote:
> > WARNING: at kernel/auditsc.c:859 audit_log_execve_info() (Not tainted)
> >
> > Call Trace:
> > [] audit_log_exit+0x5d7/0x964
> > [] trace_hardirqs_on+0x12e/0x151
> > [] audit_
On Fri, Jul 27, 2007 at 05:11:22PM -0400, Steve Grubb wrote:
> On Friday 27 July 2007 17:03:59 Alexander Viro wrote:
> > On Fri, Jul 27, 2007 at 04:13:10PM -0400, Steve Grubb wrote:
> > > WARNING: at kernel/auditsc.c:859 audit_log_execve_info() (Not tainted)
> > >
> > > Call Trace:
> > > [] audit_
On Fri, 2007-07-27 at 16:57 -0400, Steve Grubb wrote:
> I don't know of anything special its a fully updated rawhide machine. I am
> not
> running any tests, this is at the prompt in runlevel 3. I have audit=1 as a
> boot parameter in grub.conf and very simple audit rules for that machine:
>
>
On Fri, 2007-07-27 at 23:55 +0200, Peter Zijlstra wrote:
> On Fri, 2007-07-27 at 16:57 -0400, Steve Grubb wrote:
>
> > I don't know of anything special its a fully updated rawhide machine. I am
> > not
> > running any tests, this is at the prompt in runlevel 3. I have audit=1 as a
> > boot para
On Sat, 2007-07-28 at 00:06 +0200, Peter Zijlstra wrote:
> On Fri, 2007-07-27 at 23:55 +0200, Peter Zijlstra wrote:
> > On Fri, 2007-07-27 at 16:57 -0400, Steve Grubb wrote:
> >
> > > I don't know of anything special its a fully updated rawhide machine. I
> > > am not
> > > running any tests, th
On Fri, 2007-07-27 at 16:13 -0400, Steve Grubb wrote:
> Hi,
>
> I was testing our rawhide kernel and I'm scrolling these errors:
>
> WARNING: at kernel/auditsc.c:859 audit_log_execve_info() (Not tainted)
>
> Call Trace:
> [] audit_log_exit+0x5d7/0x964
> [] trace_hardirqs_on+0x12e/0x151
> [] a
On Sat, 28 Jul 2007 00:55:18 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> - if (!ret) {
> + if (ret) {
> WARN_ON(1);
> send_sig(SIGKILL, current, 0);
> }
fwiw, that could now become
if (WARN_ON(ret))
On Friday 27 July 2007 18:55:18 Peter Zijlstra wrote:
> copy_from_user() returns the number of bytes not copied, hence 0 is the
> expected output.
>
> axi->mm might not be valid anymore when not equal to current->mm, do not
> dereference before checking that - thanks to Al for spotting that.
>
> Si
20 matches
Mail list logo
