7:59 a.m.
On Sat, 2005-05-21 at 19:53 -0400, Rob Myers wrote:
On Sun, 2005-05-22 at 00:20 +0100, David Woodhouse wrote:
> On Sat, 2005-05-21 at 19:06 -0400, Rob Myers wrote:
> > i attempted to send this to linux-audit but it appears to be caught by
> > the moderator...
>
> Hm. I don't moderate that list so I can't see why. What did the message
> say was the reason?
because i'm not subscribed to the list. its only been a couple of days,
but the moderator hasn't let me subscibe yet.
Hmm. I'm not sure who does moderate it. I'll investigate; perhaps I
should take over that task.
> > like audit.45, audit.47 also says "VFS: Busy inodes
after unmount.
> > Self-destruct in 5 seconds. Have a nice day..." during shutdown.
>
> Does this happen only after you've set filesystem watches?
after some testing watches in general appear to be fine. i only get the
message if i set a watch on /var/log/audit like so:
auditctl -w /var/log/audit -k fk_var_log_audit -prwea
OK, thanks. This message is Cc'd to the list so that the IBM developer
who is working on that can see it.
--
dwmw2
10:04 a.m.
New subject: audit.47
On Sunday 22 May 2005 07:59, David Woodhouse wrote:
On Sat, 2005-05-21 at 19:53 -0400, Rob Myers wrote:
> On Sun, 2005-05-22 at 00:20 +0100, David Woodhouse wrote:
> > On Sat, 2005-05-21 at 19:06 -0400, Rob Myers wrote:
> > > i attempted to send this to linux-audit but it appears to be caught by
> > > the moderator...
> >
> > Hm. I don't moderate that list so I can't see why. What did the
message
> > say was the reason?
>
> because i'm not subscribed to the list. its only been a couple of days,
> but the moderator hasn't let me subscibe yet.
Hmm. I'm not sure who does moderate it. I'll investigate; perhaps I
should take over that task.
I believe Peter Martucelli (sp?) moderates the list...
-tim
10:31 a.m.
New subject: audit.47
Hello,
On Mon, 2005-05-23 at 11:04, Timothy R. Chavez wrote:
On Sunday 22 May 2005 07:59, David Woodhouse wrote:
> On Sat, 2005-05-21 at 19:53 -0400, Rob Myers wrote:
> > On Sun, 2005-05-22 at 00:20 +0100, David Woodhouse wrote:
> > > On Sat, 2005-05-21 at 19:06 -0400, Rob Myers wrote:
> > > > i attempted to send this to linux-audit but it appears to be caught
by
> > > > the moderator...
> > >
> > > Hm. I don't moderate that list so I can't see why. What did the
message
> > > say was the reason?
> >
> > because i'm not subscribed to the list. its only been a couple of days,
> > but the moderator hasn't let me subscibe yet.
>
> Hmm. I'm not sure who does moderate it. I'll investigate; perhaps I
> should take over that task.
>
I believe Peter Martucelli (sp?) moderates the list...
Yes I do. I cleared the posts this morning. Subscribers to the list
need to be accepted before they can post.
Regards,
Peter
1:49 p.m.
New subject: audit.47
On Mon, 2005-05-23 at 11:31 -0400, Peter Martuccelli wrote:
Hello,
On Mon, 2005-05-23 at 11:04, Timothy R. Chavez wrote:
> I believe Peter Martucelli (sp?) moderates the list...
>
>
Yes I do. I cleared the posts this morning. Subscribers to the list
need to be accepted before they can post.
with auditctl from audit-0.8.2-2 auditctl -D deletes all rules, but not
all watch lists. is there an equivalent to -D to delete all watch
lists? is it possible to make -D also delete watch lists?
for now i added a loop to clear these lists in my auditd init script:
--- /etc/init.d/auditd.orig 2005-05-23 13:34:08.819954823 -0400
+++ /etc/init.d/auditd 2005-05-23 13:41:35.517872333 -0400
@@ -71,6 +71,13 @@ stop(){
killproc $prog
RETVAL=$?
echo
+
+ # remove stale watches
+ for watch in `/sbin/auditctl -l | /bin/grep ^AUDIT_WATCH_LIST
| /bin/awk -Fpath= '{print $2}' | /bin/awk -F, '{print $1}'`
+ do
+ /sbin/auditctl -W ${watch} >/dev/null
+ done
+
rm -f /var/lock/subsys/auditd
return $RETVAL
}
also, i managed to trigger an oops with audit.47, which i have not been
able to repeat. i'll attach it in case it is useful.
and thanks peter, i appear to be all set up.
rob.
2:01 p.m.
New subject: audit.47
On Monday 23 May 2005 14:49, Rob Myers wrote:
with auditctl from audit-0.8.2-2 auditctl -D deletes all rules, but
not
all watch lists. is there an equivalent to -D to delete all watch
lists? is it possible to make -D also delete watch lists?
I've been waiting for the file system audit code to work before doing anything
else with it. I haven't checked the .47 kernel yet.
-Steve
2:12 p.m.
New subject: audit.47
On Mon, 2005-05-23 at 15:01 -0400, Steve Grubb wrote:
On Monday 23 May 2005 14:49, Rob Myers wrote:
> with auditctl from audit-0.8.2-2 auditctl -D deletes all rules, but not
> all watch lists. is there an equivalent to -D to delete all watch
> lists? is it possible to make -D also delete watch lists?
I've been waiting for the file system audit code to work before doing anything
else with it. I haven't checked the .47 kernel yet.
okay. thanks for the info.
rob.
10:57 a.m.
New subject: audit.47
On Mon, 2005-05-23 at 11:31 -0400, Peter Martuccelli wrote:
> I believe Peter Martucelli (sp?) moderates the list...
>
Yes I do. I cleared the posts this morning. Subscribers to the list
need to be accepted before they can post.
Can you turn off the Reply-To setting please?
http://www.unicom.com/pw/reply-to-harmful.html
--
dwmw2
11:55 a.m.
New subject: audit.47
* David Woodhouse (dwmw2(a)infradead.org) wrote:
On Mon, 2005-05-23 at 11:31 -0400, Peter Martuccelli wrote:
> > I believe Peter Martucelli (sp?) moderates the list...
> >
> Yes I do. I cleared the posts this morning. Subscribers to the list
> need to be accepted before they can post.
>
Can you turn off the Reply-To setting please?
http://www.unicom.com/pw/reply-to-harmful.html
Yes please, I second that.
thanks,
-chris
12:23 p.m.
New subject: audit.47
Hello,
On Thu, 2005-05-26 at 12:55, Chris Wright wrote:
* David Woodhouse (dwmw2(a)infradead.org) wrote:
> On Mon, 2005-05-23 at 11:31 -0400, Peter Martuccelli wrote:
> > > I believe Peter Martucelli (sp?) moderates the list...
> > >
> > Yes I do. I cleared the posts this morning. Subscribers to the list
> > need to be accepted before they can post.
> >
> Can you turn off the Reply-To setting please?
>
> http://www.unicom.com/pw/reply-to-harmful.html
Yes please, I second that.
I have turned off the Reply-To header for the list. Lets see how this
post shows up on the list...
Regards,
Peter
12:43 p.m.
New subject: audit.47 filesystem problems (reported by Rob Myers)
Ok,
Let me be clear on the two problems Rob Myers has brought up.
Problem 1:
When shutting down the system one gets the following VFS notification:
"VFS: Busy inodes after unmount...."
Diagnosis:
I believe this has to do with the fact that when we set watches, we pin the
dentry in memory. When we pin the dentry in memory, we effectively pin the
inode associated with it in memory as well. When we unmount a file system
with watches in it, whether we're shutting down or not, because we still have
a reference to the dentry, we should see this VFS notification.
Solution:
This could be tricky. Ideally we want to unpin all pinned dentries right
before a umount. This could get ugly, right?
The other solution is to just assume the administrator is only ever going to
umount a watched file system when they shut down and that we should then,
from user space, remove all watches prior to shut down.
Problem 2:
An OOPS when referencing a NULL pointer when watching /var/audit/audit.log in
an SMP environment which has not yet been reproduced.
Diagnosis:
Because this has not be reproducible and we're in an SMP environment its
probably safe to say there is a race. Because the OOPs occurred from within
permission() and we're dealing with file system watches it is safe to assume
that the race occurred somewhere in or under audit_notify_watch().
Solution:
None yet. I'll be looking into this right now
Do I have a clear understanding of the situation?
-tim
2:05 p.m.
New subject: audit.47 filesystem problems (reported by Rob Myers)
On Tuesday 24 May 2005 12:43, Timothy R. Chavez wrote:
<snip>
Problem 2:
An OOPS when referencing a NULL pointer when watching /var/audit/audit.log in
an SMP environment which has not yet been reproduced.
Diagnosis:
Because this has not be reproducible and we're in an SMP environment its
probably safe to say there is a race. Because the OOPs occurred from within
permission() and we're dealing with file system watches it is safe to assume
that the race occurred somewhere in or under audit_notify_watch().
Solution:
Ok, just looking at audit_notify_watch() in kernel:auditsc.c,
int audit_notify_watch(struct inode *inode, int mask)
{
int ret = 0;
struct audit_context *context = current->audit_context;
struct audit_aux_data_watched *ax;
struct audit_wentry *wentry = NULL;
if (likely(!audit_enabled))
goto audit_notify_watch_exit;
if (!inode)
goto audit_notify_watch_exit;
Possibly in an SMP environment there could be a race here
where we're trying to get a reference to inode->i_audit->wentry,
we pass the check in audit_wentry_get() to check if it's still OK,
then another CPU changes it, such that it becomes invalid in
some way (ie: NULL). With the read_lock() we force anything
that's interested in this i_audit->wentry to block until we got
the reference successfully. Does this make sense?
read_lock(&inode->i_audit->lock);
wentry = audit_wentry_get(inode->i_audit->wentry);
if (!wentry)
goto audit_notify_watch_exit;
read_unlock(&inode->i_audit->lock);
-tim
2:07 p.m.
New subject: audit.47 filesystem problems (reported by Rob Myers)
On Tuesday 24 May 2005 14:05, Timothy R. Chavez wrote:
On Tuesday 24 May 2005 12:43, Timothy R. Chavez wrote:
<snip>
> Problem 2:
>
> An OOPS when referencing a NULL pointer when watching /var/audit/audit.log in
> an SMP environment which has not yet been reproduced.
>
> Diagnosis:
>
> Because this has not be reproducible and we're in an SMP environment its
> probably safe to say there is a race. Because the OOPs occurred from within
> permission() and we're dealing with file system watches it is safe to assume
> that the race occurred somewhere in or under audit_notify_watch().
>
> Solution:
>
Ok, just looking at audit_notify_watch() in kernel:auditsc.c,
int audit_notify_watch(struct inode *inode, int mask)
{
int ret = 0;
struct audit_context *context = current->audit_context;
struct audit_aux_data_watched *ax;
struct audit_wentry *wentry = NULL;
if (likely(!audit_enabled))
goto audit_notify_watch_exit;
if (!inode)
goto audit_notify_watch_exit;
Possibly in an SMP environment there could be a race here
where we're trying to get a reference to inode->i_audit->wentry,
we pass the check in audit_wentry_get() to check if it's still OK,
then another CPU changes it, such that it becomes invalid in
some way (ie: NULL). With the read_lock() we force anything
that's interested in this i_audit->wentry to block until we got
the reference successfully. Does this make sense?
read_lock(&inode->i_audit->lock);
wentry = audit_wentry_get(inode->i_audit->wentry);
if (!wentry)
goto audit_notify_watch_exit;
read_unlock(&inode->i_audit->lock);
*cough* of course I'd want to release the lock of !wentry :-) *cough*
-tim
7149
days inactive
7153
days old
linux-audit@lists.linux-audit.osci.io
12 comments
6 participants
participants (6)
-
Chris Wright -
David Woodhouse -
Peter Martuccelli -
Rob Myers -
Steve Grubb -
Timothy R. Chavez