Re: [RFC][PATCH 10/11] security: AppArmor - Add flags to d_path

[Tony Jones <tonyj@suse.de>]

On Wed, Apr 19, 2006 at 11:12:48PM +0100, Christoph Hellwig wrote:
> On Wed, Apr 19, 2006 at 10:50:26AM -0700, Tony Jones wrote:
> > This patch adds a new function d_path_flags which takes an additional flags
> > parameter.   Adding a new function rather than ammending the existing d_path
> > was done to avoid impact on the current users.
> > 
> > It is not essential for inclusion with AppArmor (the apparmor_mediation.patch
> > can easily be revised to use plain d_path) but it enables cleaner code 
> > ["(delete)" handling] and closes a loophole with pathname generation for 
> > chrooted tasks. 
> > 
> > It currently adds two flags:
> > 
> > DPATH_SYSROOT:
> > 	d_path should generate a path from the system root rather than the
> > 	task's current root. 
> > 
> > 	For AppArmor this enables generation of absolute pathnames in all
> > 	cases.  Currently when a task is chrooted, file access is reported
> > 	relative to the chroot.  Because it is currently not possible to 
> > 	obtain the absolute path in an SMP safe way, without this patch 
> > 	AppArmor will have to report chroot-relative pathnames.
> 
> This is utter bullshit.  There is no such thing as a system root,
> and should not rely on pathes making any sense for anything but the
> process using at at this point of time.  This stuff will not get in either
> in d_path or whatever duplicate of it you'd try to submit.

You are correct on calling BS in that I was wrong to refer to it as the
"system root".  When a task chroots relative to it's current namespace, we
are interested in the path back to the root of that namespace, rather than
to the chroot.  I believe the patch as stands achieves this, albeit with
some changing of comments.

thanks!

Tony