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