Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Linda Knippers <linda.knippers@hp.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] IPC_SET_PERM cleanup
Date: Tue, 09 May 2006 11:34:58 -0400	[thread overview]
Message-ID: <4460B6A2.7060801@hp.com> (raw)
In-Reply-To: <200605091121.21457.sgrubb@redhat.com>

>>How it is easier/better?
> 
> Much easier for the user. For example, the user might be searching for uid. 
> Should the user have to specify new_uid ? Would they also need to search for 
> old_uid? Would they have to know all the possible variations on uid?

If someone is looking for the records for a particular uid, wouldn't
they expect to get the records generated by someone with that uid?
Picking up something with the new_uid wouldn't be correct in my opinion
since its data relating, really an argument for the syscall, not related
to who caused the audit record to be emitted.

> We had this discussion on the audit list back in March while discussing the 
> Audit Parsing Library.
> 
> https://www.redhat.com/archives/linux-audit/2006-March/msg00186.html
> 
> I thought it was settled at that time. If this was brought up on the LSPP 
> telecon I missed it.

It didn't seem setttled, although you were the last to reply.  I think
the discussion on the LSPP list is what initiated the mail exchange.

> Might make it tougher too. For example, suppose someone wanted to find auid = 
> 520. The user space object manager, dbus, has a auid of -1, and is not what 
> we want. The sender auid is what we want. So, by having a space, we still 
> match the sender auid = 520. The word to the left is to give context to a 
> human reading the raw record, but the search utility should still match the 
> auid value even if it has sender before it. If we combine field names, I 
> think I'll have to maintain a table of field names to types so that ausearch 
> can make sense of the field's contents no matter what the name is.

The auid is an interesting case where the auid in the record isn't very
interesting and we're relying on something in the user message.  I think
it still could be interesting to distinguish between the two types of
auid.

At this point there are already a bunch of uid fields (auid, uid, euid,
suid, fsuid, iuid, ouid) in various audit records, and a similar set
of guid files, so would you be happier with nuid, ngid, etc?

-- ljk

  reply	other threads:[~2006-05-09 15:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 20:19 [PATCH] IPC_SET_PERM cleanup Linda Knippers
2006-05-05 20:42 ` Steve Grubb
2006-05-05 20:59   ` Linda Knippers
2006-05-09 14:51     ` Klaus Weidner
2006-05-05 21:26 ` Linda Knippers
2006-05-08 18:29 ` Dustin Kirkland
2006-05-08 18:29 ` Dustin Kirkland
2006-05-08 19:06   ` Linda Knippers
2006-05-09 14:59   ` Klaus Weidner
2006-05-09 15:05     ` Steve Grubb
2006-05-09 15:12       ` Linda Knippers
2006-05-09 15:21         ` Steve Grubb
2006-05-09 15:34           ` Linda Knippers [this message]
2006-05-09 15:55             ` Steve Grubb
2006-05-09 16:33               ` Klaus Weidner
2006-05-09 17:47               ` Linda Knippers
2006-05-09 18:15                 ` Klaus Weidner
2006-05-09 18:27                   ` Linda Knippers
2006-05-09 19:11                     ` Steve Grubb
2006-05-09 20:10                       ` Klaus Weidner
2006-05-09 20:36                         ` Klaus Weidner
2006-05-09 20:46                           ` Linda Knippers
2006-05-10 14:02                             ` Steve Grubb
2006-05-10 16:29                               ` Klaus Weidner
2006-05-10 17:02                                 ` Dustin Kirkland
2006-05-10 17:11                                   ` Klaus Weidner
2006-05-10 17:22                                     ` Linda Knippers
2006-05-10 17:29                                     ` Steve Grubb
2006-05-10 18:10                                       ` Klaus Weidner
2006-05-10 17:28                                 ` Steve Grubb
2006-05-10 18:05                                   ` Linda Knippers
2006-05-10 18:20                                     ` Steve Grubb
2006-05-09 15:53           ` Amy Griffis
2006-05-09 15:07 ` Steve Grubb

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=4460B6A2.7060801@hp.com \
    --to=linda.knippers@hp.com \
    --cc=linux-audit@redhat.com \
    --cc=sgrubb@redhat.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