RE: Linux 2.6.20-rc6
> Venkat, I think we should fix this by embedding the flow_cache_genid > bumps into selinux_netlbl_cache_invalidate() and > selnl_notify_policyload(), or something like that. > Sure. Sending a patch under separate cover in a minute. > That way we don't have to pepper CONFIG_XFRM ifdefs all over > services.c > > Any better ideas? I'm actually surprised this code gets built > at all when CONFIG_XFRM is disabled to be honest. :-) Me too :) My apologies... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.20-rc6: known unfixed regressions (part 2)
FYI- The patch can be viewed here: http://marc.theaimsgroup.com/?l=linux-netdev&m=116983297300536&w=2 > -Original Message- > From: Michal Piotrowski [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 1:04 PM > To: Adrian Bunk > Cc: Linus Torvalds; Andrew Morton; Linux Kernel Mailing List; > Uwe Bugla; > [EMAIL PROTECTED]; linux-ide@vger.kernel.org; > [EMAIL PROTECTED]; Gerhard Dirschl; Christoph Hellwig; > [EMAIL PROTECTED]; Michal Piotrowski; Venkat Yekkirala; David Miller; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org; Livio > Soares; Paul Mackerras; [EMAIL PROTECTED]; Cijoml Cijomlovic > Cijomlov; Nick Piggin; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Malte > Schröder; Vladimir V. Saveliev; [EMAIL PROTECTED]; Sami Farin; > David Chinner; [EMAIL PROTECTED] > Subject: Re: 2.6.20-rc6: known unfixed regressions (part 2) > > > Hi, > > Adrian Bunk napisał(a): > > This email lists some known regressions in 2.6.20-rc6 > compared to 2.6.19 > > that are not yet fixed in Linus' tree. > > > > If you find your name in the Cc header, you are either > submitter of one > > of the bugs, maintainer of an affectected subsystem or > driver, a patch > > of you caused a breakage or I'm considering you in any > other way possibly > > involved with one or more of these issues. > > > > Due to the huge amount of recipients, please trim the Cc > when answering. > > > > > > Subject: SELinux compile error with CONFIG_XFRM=n > > References : http://lkml.org/lkml/2007/1/25/233 > > Submitter : Michal Piotrowski <[EMAIL PROTECTED]> > > Caused-By : Venkat Yekkirala <[EMAIL PROTECTED]> > > commit 334c85569b8adeaa820c0f2fab3c8f0a9dc8b92e > > Handled-By : Venkat Yekkirala <[EMAIL PROTECTED]> > > David Miller <[EMAIL PROTECTED]> > > Status : problem is being discussed > > > > Venkat Yekkirala has sent me a patch that fixed this build problem. > > Thanks! > > Regards, > Michal > > -- > Michal K. K. Piotrowski > LTG - Linux Testers Group > (http://www.stardust.webpages.pl/ltg/) > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] xfrm_policy delete security check misplaced
> > Signed-off-by: Eric Paris <[EMAIL PROTECTED]> Acked-by: Venkat Yekkirala <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add xfrm policy change auditing to pfkey_spdget
> pfkey_spdget neither had an LSM security hook nor auditing for the > removal of xfrm_policy structs. The security hook was added > when it was > moved into xfrm_policy_byid instead of the callers to that function by > my earlier patch and this patch adds the auditing hooks as well. > > Signed-off-by: Eric Paris <[EMAIL PROTECTED]> Acked-by: Venkat Yekkirala <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] xfrm_policy delete security check misplaced
> Also, [Joy cc'd] deletions here needn't be audited? OK, I see the next patch addressed this :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] xfrm_policy delete security check misplaced
> @@ -2552,7 +2550,7 @@ static int pfkey_spdget(struct sock > *sk, struct sk_buff *skb, struct sadb_msg *h > return -EINVAL; > > xp = xfrm_policy_byid(XFRM_POLICY_TYPE_MAIN, dir, > pol->sadb_x_policy_id, > - hdr->sadb_msg_type == SADB_X_SPDDELETE2); > + hdr->sadb_msg_type == > SADB_X_SPDDELETE2, &err); > if (xp == NULL) > return -ENOENT; I guess you meant to do this here? else if (err) return err; Also, [Joy cc'd] deletions here needn't be audited? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] xfrm audit hook misplaced in pfkey_delete and xfrm_del_sa
> Inside pfkey_delete and xfrm_del_sa the audit hooks were not called if > there was any permission/security failures in attempting to do the del > operation (such as permission denied from security_xfrm_state_delete). > This patch moves the audit hook to the exit path such that > all failures > (and successes) will actually get audited. Not sure ALL failures are being audited this way elsewhere, but I guess they would catchup in course of time. > > Signed-off-by: Eric Paris <[EMAIL PROTECTED]> Acked-by: Venkat Yekkirala <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] xfrm_policy delete security check misplaced
> > > > > > Signed-off-by: Eric Paris <[EMAIL PROTECTED]> > > Acked-by: Venkat Yekkirala <[EMAIL PROTECTED]> > > What about your previous comment: > > "I guess you meant to do this here? > else if (err) > return err; " I saw that this was taken care of in patch-2 for the delete case, but while err isn't currently applicable to the non-delete case, it would be proper/complete for err to still be handled for the non-delete case. Thanks for asking. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
