[PATCH] fix ppid bug in 2.6.18 kernel

[PATCH] fix ppid bug in 2.6.18 kernel

[Steve Grubb]

Hello,

During some troubleshooting, I found that ppid was accidentally omitted from
the legacy rule section. This resulted in EINVAL for any rule with ppid sent
with AUDIT_ADD.

Signed-off-by: Steve Grubb <sgrubb@redhat.com>


diff -urp linux-2.6.17.x86_64.orig/kernel/auditfilter.c linux-2.6.17.x86_64/kernel/auditfilter.c
--- linux-2.6.17.x86_64.orig/kernel/auditfilter.c	2006-08-26 13:50:19.000000000 -0400
+++ linux-2.6.17.x86_64/kernel/auditfilter.c	2006-08-26 13:52:30.000000000 -0400
@@ -413,6 +413,7 @@ static struct audit_entry *audit_rule_to
 		case AUDIT_PERS:
 		case AUDIT_ARCH:
 		case AUDIT_MSGTYPE:
+		case AUDIT_PPID:
 		case AUDIT_DEVMAJOR:
 		case AUDIT_DEVMINOR:
 		case AUDIT_EXIT:

Re: [PATCH] fix ppid bug in 2.6.18 kernel

[Amy Griffis]

Steve Grubb wrote:  [Sat Aug 26 2006, 02:06:20PM EDT]
> Hello,
> 
> During some troubleshooting, I found that ppid was accidentally omitted from
> the legacy rule section. This resulted in EINVAL for any rule with ppid sent
> with AUDIT_ADD.

AUDIT_PPID was recently added, so shouldn't be supported for the
legacy structure.  Instead auditctl should use struct audit_rule_data
for rules with AUDIT_PPID.

> Signed-off-by: Steve Grubb <sgrubb@redhat.com>
> 
> 
> diff -urp linux-2.6.17.x86_64.orig/kernel/auditfilter.c linux-2.6.17.x86_64/kernel/auditfilter.c
> --- linux-2.6.17.x86_64.orig/kernel/auditfilter.c	2006-08-26 13:50:19.000000000 -0400
> +++ linux-2.6.17.x86_64/kernel/auditfilter.c	2006-08-26 13:52:30.000000000 -0400
> @@ -413,6 +413,7 @@ static struct audit_entry *audit_rule_to
>  		case AUDIT_PERS:
>  		case AUDIT_ARCH:
>  		case AUDIT_MSGTYPE:
> +		case AUDIT_PPID:
>  		case AUDIT_DEVMAJOR:
>  		case AUDIT_DEVMINOR:
>  		case AUDIT_EXIT:
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 

Re: [PATCH] fix ppid bug in 2.6.18 kernel

[Steve Grubb]

On Monday 28 August 2006 14:59, Amy Griffis wrote:
> AUDIT_PPID was recently added, so shouldn't be supported for the
> legacy structure. 

There's no harm in adding it here. Lets old userspace work with new kernels.

> Instead auditctl should use struct audit_rule_data for rules with
> AUDIT_PPID.

The way that it currently works is that it uses the old structures until it 
decides that it needs the new structures (key, watch, etc). It needs to do 
this so that people can boot into old kernels and issue audit commands. FC5 
includes 2.6.16 kernel and I will be pushing the current audit userspace into 
FC5 when we know that everything works fine for 2.6.18. So, FC5 will have 
users with both kinds of kernels.

I will be removing all the old audit_rule stuff soon so that auditctl uses 
nothing but the new interface. Somewhere around 2.6.20, we should pull all 
the old audit_rule struct stuff from the kernel, too.

But in the mean time, we should support both equally when it makes sense.

-Steve

Re: [PATCH] fix ppid bug in 2.6.18 kernel

[Amy Griffis]

Steve Grubb wrote:  [Mon Aug 28 2006, 03:22:14PM EDT]
> On Monday 28 August 2006 14:59, Amy Griffis wrote:
> > AUDIT_PPID was recently added, so shouldn't be supported for the
> > legacy structure. 
> 
> There's no harm in adding it here. Lets old userspace work with new kernels.
> 
> > Instead auditctl should use struct audit_rule_data for rules with
> > AUDIT_PPID.
> 
> The way that it currently works is that it uses the old structures until it 
> decides that it needs the new structures (key, watch, etc). It needs to do 
> this so that people can boot into old kernels and issue audit commands. FC5 
> includes 2.6.16 kernel and I will be pushing the current audit userspace into 
> FC5 when we know that everything works fine for 2.6.18. So, FC5 will have 
> users with both kinds of kernels.
> 
> I will be removing all the old audit_rule stuff soon so that auditctl uses 
> nothing but the new interface. Somewhere around 2.6.20, we should pull all 
> the old audit_rule struct stuff from the kernel, too.

Okay, I'm glad to hear it.  My concern was not to support the legacy
structure indefinitely.

> But in the mean time, we should support both equally when it makes sense.
> 
> -Steve
>