linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: John Johansen <jjohansen@suse.de>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [AppArmor 00/44] AppArmor security module overview
Date: Tue, 3 Jul 2007 02:20:20 -0400	[thread overview]
Message-ID: <20070703062020.GA5433@redhat.com> (raw)
In-Reply-To: <20070626194700.5b0ff477.akpm@linux-foundation.org>

On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:

 > 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.

How is this different from Red Hat wearing the permanent cost of
carrying Execshield or other vetoed-by-upstream features ?

Given the choice, I'd ship a kernel for Fedora with nothing added
that isn't upstream, but we have something of a legacy from our
dumber days. (Though we've managed to drop lots of the more invasive
stuff over time thankfully.. 4g4g for eg).

 > 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.  The idea of granting exceptions to our usual acceptance
criteria just because "some distro shipped it" strikes me as wrong
on so many levels, regardless of its technical flaws.

And this isn't just because this is a patch from a competitor,
I'd expect the exact same criteria to be applied if I tried
to ram execshield etc down everyones throats.

	Dave

-- 
http://www.codemonkey.org.uk

  parent reply	other threads:[~2007-07-03  6:20 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-26 23:07 [AppArmor 00/44] AppArmor security module overview jjohansen
2007-06-26 23:07 ` [AppArmor 01/44] Pass struct vfsmount to the inode_create LSM hook jjohansen
2007-06-30  9:29   ` Christoph Hellwig
2007-07-03 22:28     ` Andreas Gruenbacher
2007-06-26 23:07 ` [AppArmor 02/44] Pass struct path down to remove_suid and children jjohansen
2007-06-26 23:07 ` [AppArmor 03/44] Add a vfsmount parameter to notify_change() jjohansen
2007-06-26 23:08 ` [AppArmor 04/44] Pass struct vfsmount to the inode_setattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 05/44] Add struct vfsmount parameter to vfs_mkdir() jjohansen
2007-06-26 23:08 ` [AppArmor 06/44] Pass struct vfsmount to the inode_mkdir LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 07/44] Add a struct vfsmount parameter to vfs_mknod() jjohansen
2007-06-26 23:08 ` [AppArmor 08/44] Pass struct vfsmount to the inode_mknod LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 09/44] Add a struct vfsmount parameter to vfs_symlink() jjohansen
2007-06-26 23:08 ` [AppArmor 10/44] Pass struct vfsmount to the inode_symlink LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 11/44] Pass struct vfsmount to the inode_readlink " jjohansen
2007-06-26 23:08 ` [AppArmor 12/44] Add struct vfsmount parameters to vfs_link() jjohansen
2007-06-26 23:08 ` [AppArmor 13/44] Pass the struct vfsmounts to the inode_link LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 14/44] Add a struct vfsmount parameter to vfs_rmdir() jjohansen
2007-06-26 23:08 ` [AppArmor 15/44] Pass struct vfsmount to the inode_rmdir LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 16/44] Call lsm hook before unhashing dentry in vfs_rmdir() jjohansen
2007-06-26 23:08 ` [AppArmor 17/44] Add a struct vfsmount parameter to vfs_unlink() jjohansen
2007-06-26 23:08 ` [AppArmor 18/44] Pass struct vfsmount to the inode_unlink LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 19/44] Add struct vfsmount parameters to vfs_rename() jjohansen
2007-06-26 23:08 ` [AppArmor 20/44] Pass struct vfsmount to the inode_rename LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 21/44] Add a struct vfsmount parameter to vfs_setxattr() jjohansen
2007-06-26 23:08 ` [AppArmor 22/44] Pass struct vfsmount to the inode_setxattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 23/44] Add a struct vfsmount parameter to vfs_getxattr() jjohansen
2007-06-26 23:08 ` [AppArmor 25/44] Add a struct vfsmount parameter to vfs_listxattr() jjohansen
2007-06-26 23:08 ` [AppArmor 26/44] Pass struct vfsmount to the inode_listxattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 27/44] Add a struct vfsmount parameter to vfs_removexattr() jjohansen
2007-06-26 23:08 ` [AppArmor 28/44] Pass struct vfsmount to the inode_removexattr LSM hook jjohansen
2007-06-26 23:08 ` [AppArmor 29/44] Fix __d_path() for lazy unmounts and make it unambiguous jjohansen
2007-06-26 23:08 ` [AppArmor 30/44] Make d_path() consistent across mount operations jjohansen
2007-06-26 23:08 ` [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames jjohansen
2007-06-28 16:12   ` James Morris
2007-06-28 18:15     ` Andreas Gruenbacher
2007-07-03 13:49       ` Stephen Smalley
2007-07-03 20:01         ` Andreas Gruenbacher
2007-06-26 23:08 ` [AppArmor 33/44] Pass struct file down the inode_*xattr security LSM hooks jjohansen
2007-06-26 23:08 ` [AppArmor 34/44] Factor out sysctl pathname code jjohansen
2007-06-26 23:08 ` [AppArmor 35/44] Allow permission functions to tell between parent and leaf checks jjohansen
2007-06-26 23:08 ` [AppArmor 36/44] Export audit subsystem for use by modules jjohansen
2007-06-26 23:08 ` [AppArmor 37/44] AppArmor: Main Part jjohansen
2007-06-26 23:08 ` [AppArmor 38/44] AppArmor: Module and LSM hooks jjohansen
2007-06-26 23:08 ` [AppArmor 39/44] AppArmor: Profile loading and manipulation, pathname matching jjohansen
2007-06-26 23:08 ` [AppArmor 40/44] AppArmor: all the rest jjohansen
2007-06-26 23:08 ` [AppArmor 41/44] Add AppArmor LSM to security/Makefile jjohansen
2007-06-26 23:08 ` [AppArmor 42/44] Switch to vfs_permission() in do_path_lookup() jjohansen
2007-06-26 23:08 ` [AppArmor 43/44] Switch to vfs_permission() in sys_fchdir() jjohansen
2007-06-26 23:08 ` [AppArmor 44/44] Fix file_permission() jjohansen
2007-06-26 23:52 ` [AppArmor 00/44] AppArmor security module overview Andrew Morton
2007-06-27  2:24   ` John Johansen
2007-06-27  2:47     ` Andrew Morton
2007-06-27  6:43       ` John Johansen
2007-06-27 15:11       ` Adrian Bunk
2007-06-27 21:06         ` Crispin Cowan
2007-06-27 21:29           ` Sean
2007-06-27 22:46             ` Crispin Cowan
2007-06-27 23:05               ` David Miller
2007-06-28  0:27                 ` Casey Schaufler
2007-06-28  0:34                   ` David Miller
2007-06-28 10:23                   ` Alan Cox
2007-06-28 13:50                   ` Bill O'Donnell
2007-06-28 11:27                 ` Tilman Schmidt
2007-06-28 12:48                   ` Adrian Bunk
2007-06-27 22:41         ` Andreas Dilger
2007-07-02 16:45         ` Eric W. Biederman
2007-07-02 19:31           ` Casey Schaufler
2007-07-02 20:15             ` Christoph Hellwig
2007-07-02 21:09               ` Casey Schaufler
2007-07-03 16:33               ` Andreas Gruenbacher
2007-06-29 18:06       ` Pavel Machek
2007-07-03  6:20       ` Dave Jones [this message]
2007-06-27 10:58     ` Kyle Moffett
2007-06-27 13:37       ` Andreas Gruenbacher
2007-06-27  0:32 ` [AppArmor 24/44] Pass struct vfsmount to the inode_getxattr LSM hook jjohansen
2007-06-27  0:32 ` [AppArmor 31/44] Add d_namespace_path() to compute namespace relative pathnames jjohansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070703062020.GA5433@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jjohansen@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).