On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 16:07:56 -0700
> jjohansen@suse.de wrote:
> 
> > This post contains patches to include the AppArmor application security
> > framework, with request for inclusion into -mm for wider testing.
> 
> Patches 24 and 31 didn't come through.
> 
yes, sorry about that I had a very odd failure authetication failure
with those two mails and missed it.

They have been recent.

> 
> so...  where do we stand with this?  Fundamental, irreconcilable
> differences over the use of pathname-based security?
> 
There certainly seems to be some differences of opinion over the use
of pathname-based-security.

> Are there any other sticking points?
> 
> 
The conditional passing of the vfsmnt mount in the vfs, as done in this
patch series, has received a NAK.  This problem results from NFS passing
a NULL nameidata into the vfs.  We have a second patch series that we
have posted for discussion that addresses this by splitting the nameidata
struct.
Message-Id: <20070626231510.883881222@suse.de>
Subject: [RFD 0/4] AppArmor - Don't pass NULL nameidata to
vfs_create/lookup/permission IOPs

other issues that have been raised are:
- AppArmor does not currently mediate IPC and network communications.
  Mediation of these is a wip
- the use of d_path to generate the pathname used for mediation when a
  file is opened.
  - Generating the pathname using a reverse walk is considered ugly
  - A buffer is alloced to store the generated path name.
  - The  buffer size has a configurable upper limit which will cause
    opens to fail if the pathname length exceeds this limit.  This
    is a fail closed behavior.
  - there have been some concerns expressed about the performance
    of this approach
  We are evaluating our options on how best to address this issue.