Re: [xfs-masters] [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible
On Mon, Jul 30, 2007 at 08:27:47AM -0400, Stephen Smalley wrote: On Mon, 2007-07-30 at 09:29 +1000, David Chinner wrote: On Sun, Jul 29, 2007 at 05:02:09PM +0200, Adrian Bunk wrote: Please correct me if any of the following assumptions is wrong: - SELinux is currently the only user of filesystem security labels shipped with the Linux kernel - if a user has SELinux enabled he wants his filesystems to support security labels Based on these assumption, it doesn't make sense to have the *FS_SECURITY user visible since we can perfectly determine automatically when turning them on makes sense. Hmmm. The code in XFS is not dependent on selinux, but this change would mean that testing the security xattr namespace would require a selinux enabled kernel. I agree that the default for these should be y and selected if selinux is enabled, but forcing us to use selinux enabled kernels (on distro's that may not support selinux) just to test the security xattr namespace is a bit of a pain. You can enable SECURITY_SELINUX in the kernel config but still have it boot disabled by default via SECURITY_SELINUX_BOOTPARAM_VALUE=0. Ok, that shouldn't cause a problem then. Objection withdrawn. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [xfs-masters] [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible
On Mon, 2007-07-30 at 09:29 +1000, David Chinner wrote: On Sun, Jul 29, 2007 at 05:02:09PM +0200, Adrian Bunk wrote: Please correct me if any of the following assumptions is wrong: - SELinux is currently the only user of filesystem security labels shipped with the Linux kernel - if a user has SELinux enabled he wants his filesystems to support security labels Based on these assumption, it doesn't make sense to have the *FS_SECURITY user visible since we can perfectly determine automatically when turning them on makes sense. Hmmm. The code in XFS is not dependent on selinux, but this change would mean that testing the security xattr namespace would require a selinux enabled kernel. I agree that the default for these should be y and selected if selinux is enabled, but forcing us to use selinux enabled kernels (on distro's that may not support selinux) just to test the security xattr namespace is a bit of a pain. You can enable SECURITY_SELINUX in the kernel config but still have it boot disabled by default via SECURITY_SELINUX_BOOTPARAM_VALUE=0. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [xfs-masters] [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible
On Sun, Jul 29, 2007 at 05:02:09PM +0200, Adrian Bunk wrote: Please correct me if any of the following assumptions is wrong: - SELinux is currently the only user of filesystem security labels shipped with the Linux kernel - if a user has SELinux enabled he wants his filesystems to support security labels Based on these assumption, it doesn't make sense to have the *FS_SECURITY user visible since we can perfectly determine automatically when turning them on makes sense. Hmmm. The code in XFS is not dependent on selinux, but this change would mean that testing the security xattr namespace would require a selinux enabled kernel. I agree that the default for these should be y and selected if selinux is enabled, but forcing us to use selinux enabled kernels (on distro's that may not support selinux) just to test the security xattr namespace is a bit of a pain. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
