[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 
	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)))

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".


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]