On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote: > 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. > sorry about that > Do you agree with the "irreconcilable" part? I think I do. > I will concede that this may be the case for some. However I am still hopeful (perhaps naive) that this isn't the case in general. > 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. Agreed, and I hope any changes that are made are for the benefit of the kernel in general and will find uses in other parts. > > 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. > Indeed, I can only appologize for the past, and offer reassurances that we intend to do our best to do, it right going forward. > > > 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. thankyou
Attachment:
pgpyJYsAVheDm.pgp
Description: PGP signature
