On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <jjohansen@xxxxxxx> wrote: > > > > 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. I was refreshed to have not been cc'ed on a lkml thread for once. I guess it couldn't last. Do you agree with the "irreconcilable" part? I think I do. I suspect that we're at the stage of having to decide between a) set aside the technical issues and grudgingly merge this stuff as a service to Suse and to their users (both of which entities are very important to us) and leave it all as an object lesson in how-not-to-develop-kernel-features. Minimisation of the impact on the rest of the kernel is of course very important here. versus b) leave it out and require that Suse wear the permanent cost and quality impact of maintaining it out-of-tree. It will still be an object lesson in how-not-to-develop-kernel-features. Sigh. Please don't put us in this position again. Get stuff upstream before shipping it to customers, OK? It ain't rocket science. > > 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@xxxxxxx> > 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. OK, useful summary, thanks. I'd encourage you to proceed apace. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
