Re: [RFC][PATCH 4/11] security: AppArmor - Core access controls

[Al Viro <viro@ftp.linux.org.uk>]

> +static int _aa_perm_dentry(struct aaprofile *active, struct dentry *dentry,
> +			   int mask, const char **pname)
> +{
> +	char *name = NULL, *failed_name = NULL;
> +	struct aa_path_data data;
> +	int error = 0, failed_error = 0, path_error,
> +	    complain = PROFILE_COMPLAIN(active);
> +
> +	/* search all paths to dentry */
> +
> +	aa_path_begin(dentry, &data);
> +	do {
> +		name = aa_path_getname(&data);
> +		if (name) {
> +			/* error here is 0 (success) or +ve (mask of perms) */
> +			error = aa_file_perm(active, name, mask);
> +
> +			/* access via any path is enough */
> +			if (complain || error == 0)
> +				break; /* Caller must free name */
> +
> +			/* Already have an path that failed? */
> +			if (failed_name) {
> +				aa_put_name(name);
> +			} else {
> +				failed_name = name;
> +				failed_error = error;
> +			}
> +		}
> +	} while (name);

Is that a joke?  Are you really proposing to do _that_ on anything resembling
a hot path?

BTW, the problems here really have nothing to do with namespaces or
lazy umount, seeing that it's whitelisting.  Moderate amount of bindings
will kill you here.  So much that I suspect that one-time overhead of
creating a namespace and umounting / remounting noexec / etc. on
execve() will be cheaper than all this crap.
-
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/