[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131208221703.GB10279@madcap2.tricolour.ca>
Date: Sun, 8 Dec 2013 17:17:03 -0500
From: Richard Guy Briggs <rgb@...hat.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: linux-audit@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] smack: call WARN_ONCE() instead of calling
audit_log_start()
On Fri, Dec 06, 2013 at 10:40:56AM -0800, Casey Schaufler wrote:
> On 12/4/2013 6:45 PM, Richard Guy Briggs wrote:
> > Remove the call to audit_log() (which call audit_log_start()) and deal with
> > the errors in the caller, logging only once if the condition is met. Calling
> > audit_log_start() in this location makes buffer allocation and locking more
> > complicated in the calling tree (audit_filter_user()).
> >
> > Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
>
> I'm not opposed to this change, but have you actually tried it?
No, do you have concerns?
It is a projection based on the selinux_audit_match_rule() patch in the
same set.
> > ---
> > security/smack/smack_lsm.c | 5 ++---
> > 1 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> > index 8825375..185e2e7 100644
> > --- a/security/smack/smack_lsm.c
> > +++ b/security/smack/smack_lsm.c
> > @@ -3615,9 +3615,8 @@ static int smack_audit_rule_match(u32 secid, u32 field, u32 op, void *vrule,
> > struct smack_known *skp;
> > char *rule = vrule;
> >
> > - if (!rule) {
> > - audit_log(actx, GFP_ATOMIC, AUDIT_SELINUX_ERR,
> > - "Smack: missing rule\n");
> > + if (unlikely(!rule)) {
> > + WARN_ONCE(1, "Smack: missing rule\n");
> > return -ENOENT;
> > }
> >
>
- RGB
--
Richard Guy Briggs <rbriggs@...hat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists