Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lisa Smith <lisa.m.smith@hp.com>
To: "Timothy R. Chavez" <tinytim@us.ibm.com>
Cc: LSPP <redhat-lspp@redhat.com>, linux-audit@redhat.com
Subject: Re: [RFC: PATCH] Audit Failure Query Functionality
Date: Tue, 13 Jun 2006 17:00:47 -0400	[thread overview]
Message-ID: <448F277F.1030603@hp.com> (raw)
In-Reply-To: <1150228629.26983.35.camel@localhost.localdomain>

Tim,

>> +       /* Find the audit failure action tunable in the config file */
>> +       ret = search_audituser_conf(file, AUDIT_FAIL_KEYWORD, &nv);
>> +
>> +       if (ret == -1) {
>> +               audit_msg(LOG_WARNING, "Error in %s", file);
>>     
>
> Would you not want to use LOG_ERR here?  Or if you really did intend a
> LOG_WARNING using the word "Error" in your message might be confusing. 
>   

Good catch.  I've changed this to LOG_ERR.

>> +               return ERR;
>>     
> This is really awkward to me.  I think it makes more sense to make this
> function simply return success or failure and update a parameter passed
> to it by the user with the correct failure mode.  As it stands now, ERR
> isn't really a failure mode.  May I also suggest making your enumeration
> a little more descriptive?
>   

How about on any error IGNORE is simply returned, and the ERR mode is
eliminated?  There will still be an audit log message, so the error does
not vanish.  This means the caller will always have one of the three
failure modes to handle.

What did you have in mind to make the enumeration more descriptive?

>> +
>> +       /* Open the file for line by line reading*/
>> +       fp = fopen(file, "r");
>> +       if (fp == NULL) {
>> +               audit_msg(LOG_ERR, "Error - fdopen failed for %s (%s)",
>> +                       file, strerror(errno));
>> +               return -1;
>> +        }
>>     
>
> Why return -1, why not return errno?
>   

The caller only cares that the file could not be opened - it doesn't
matter why.  If we passes errno back, nothing would be done with that
value anyway.  The errno will be posted in the log, however, if an admin
has a need to debug a problem.

> [..]
>   
>> +
>> +       while ((bytesread = getline(&buf, &len, fp)) != -1) {
>> +
>> +               if (buf[0] == '#') {
>> +                       lineno++;
>> +                       continue;       // Ignore comments
>> +               }
>>     
>
> So will this blow up if buf[0] == ' ' ?
>   

No.  getline() will retrieve a new line from a file until there are no
more lines in the file.  After all lines have been read, getline() will
return -1 and drop out of the while loop.

> [..]
>   
>> +
>> +               /* Convert line into name-value pair */
>> +               rc = nv_split(buf, nv);
>> +               if (rc == 1) {
>> +                       audit_msg(LOG_ERR, "Error on line %d in %s", lineno,
>> +                               file);
>> +                       lineno++;
>> +                       continue;
>> +                }
>> +
>> +               /* Find the name-value pair */
>> +               if (strcmp(nv->name, keyword) == 0)
>> +               {
>> +                       fclose(fp);
>> +                       if (buf)
>>     
>
> Superfluous conditional.
>   

Fixed, thanks.

>> +       return 1;
>> +}
>> +
>> +/*
>> + *  This function parses a line looking for a keyword = value pair
>> + *  and if found, returns it in the nv structure. If the function
>> + *  returns success, the calling function is expected to free
>> + *  nv->name and nv->value.
>> + */
>> +int nv_split(char *buffer, struct nv_pair *nv)
>> +{
>> +       /* Get the name part */
>> +       char *saveptr, *ptr = NULL;
>> +       char *buf = strdup(buffer);
>> +
>> +       /* Look for = in buf */
>> +       nv->name = NULL;
>> +       nv->value = NULL;
>> +       ptr = strtok_r(buf, " =", &saveptr);
>> +       if ((ptr == NULL) || !(strcmp(ptr,"\n"))) {
>>     
>
> You can kill that strcmp, right?
>
> if (!ptr || *ptr == '\n') {
>   

Yup, corrected.

>
> You should just write a little helper routine called something like:
> 	
> 	free_nv(struct nv_pair *nv);
>
> It's obvious what it does and it consolidates some code and makes things
> look cleaner. 
>   

Great idea; will do.

Thanks for your comments.

Lisa

  reply	other threads:[~2006-06-13 21:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-13 18:52 [RFC: PATCH] Audit Failure Query Functionality Lisa Smith
2006-06-13 19:57 ` Timothy R. Chavez
2006-06-13 21:00   ` Lisa Smith [this message]
2006-06-13 21:30 ` James Antill
2006-06-14 18:05   ` Lisa Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=448F277F.1030603@hp.com \
    --to=lisa.m.smith@hp.com \
    --cc=linux-audit@redhat.com \
    --cc=redhat-lspp@redhat.com \
    --cc=tinytim@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox