Messages in this thread | | | Subject | Re: [RFC][PATCH 4/11] security: AppArmor - Core access controls | From | Stephen Smalley <> | Date | Wed, 19 Apr 2006 15:50:43 -0400 |
| |
On Wed, 2006-04-19 at 10:49 -0700, Tony Jones wrote: > +/** > + * aa_get_name - retrieve fully qualified path name > + * @dentry: relative path element > + * @mnt: where in tree > + * > + * Returns fully qualified path name on sucess, NULL on failure. > + * aa_put_name must be used to free allocated buffer. > + */ > +char *aa_get_name(struct dentry *dentry, struct vfsmount *mnt) > +{ > + char *page, *name = NULL; > + > + page = (char *)__get_free_page(GFP_KERNEL); > + if (!page) > + goto out; > + > + name = d_path_flags(dentry, mnt, page, PAGE_SIZE, > + DPATH_SYSROOT|DPATH_NODELETED);
So on every inode hook call, you end up allocating a temporary page, calling d_path (taking global dcache_lock), and you do this possibly multiple times per object (due to iterating over vfsmounts) and you may need to do it for multiple objects on a single hook call (e.g. link/rename). Is that correct?
> +/** > + * aa_perm_nameidata: interface to sd_perm accepting nameidata > + * @active: profile to check against > + * @nd: namespace data (for vfsmnt and dentry) > + * @mask: access mode requested > + */ > +int aa_perm_nameidata(struct aaprofile *active, struct nameidata *nd, int mask) > +{ > + int error = 0; > + > + if (nd) > + error = aa_perm(active, nd->dentry, nd->mnt, mask); > + > + return error; > +}
So what about the !nd case. For when permission(9) is called with a NULL nameidata. Unconditional success in that case seems a bit worrisome.
I also vaguely recall a problem with trying to use the nameidata (vfsmount, dentry) pair to d_path in SELinux for audit purposes back when avc_audit was trying to audit paths before migrating to using the audit system for that purpose. Interacted badly with rpc_pipefs upon rpc_lookup_parent, IIRC. Might want to check whether you handle it correctly.
-- Stephen Smalley National Security Agency
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |