[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 10/11] security: AppArmor - Add flags to d_path
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:
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-20 00:15    [W:0.285 / U:4.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site