[RFC][PATCH] (#6 U1) the latest incarnation

[Timothy R. Chavez]

On Thursday 24 March 2005 01:32 pm, Stephen Smalley wrote:
> On Thu, 2005-03-24 at 14:23 -0500, Stephen Smalley wrote:
> > Then I start to see some audit messages during passwd, but I shouldn't
> > have to request read access auditing in order to see modifications
> > (especially as that will generate a lot more data, e.g. upon every
> > authentication program's use of /etc/shadow).
>
> Ok, I see what is happening.  You call audit_attach_watch() from d_move,
> but you will never hit an audit_notify_watch(), hence no audit data upon
> renames until a subsequent write to the existing file (which never
> happens for /etc/shadow, as it is always re-created and renamed for each
> transaction).  So a natural question is what else should be calling
> audit_notify_watch besides permission, exec_permission_lite, and
> may_delete?  d_move?  may_create?

Though the dnotify assessment happens in a later message,  I think this is a 
good approach.  But, yes, back to expected messages missing, I was missing 
records too for unlink() -- What is boiled down to was I was making the wrong 
statement when filtering in audit_notify_watch():

static inline int may_delete(struct inode *dir,struct dentry *victim, int 
isdir)
{
	....
	audit_notify_watch(victim->d_inode, 0);
	....
}

void audit_notify_watch(struct inode *inode, int mask)
{
	.....
	// Doh! The mask==0 for may_delete's hook, thus we bottom out here
	if (!mask || (wentry->w_watch->perms && !(wentry->w_watch->perms&mask)))
		return;
	.....
}

This statement really should be:

if (mask && (wentry->w_watch->perms && !(wentry->w_watch->perms&mask)))

We treat a mask==0 as, "no permissions filtering needed", thus we don't need 
to check for it in the w_watch->perms.  We also treat a w_watch->perms==0 
(which is the default) similarly as "no permissions filtering required".

-tim