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: [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible
Quoting Adrian Bunk ([EMAIL PROTECTED]): 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. I'm not very knowledgeable on the niftier kconfig features. Is there a way to introduce some intermediate SECURITY_XATTR variable, which SECURITY_SELINUX could select, and which *_FS_SECURITY could depend on? That way patches for file capabilities (in -mm) and smack (being discussed on linux-security-module) won't have to explicitly add themselves to every one of those 'depends on' lines. thanks, -serge Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- fs/Kconfig | 82 + fs/xfs/Kconfig | 13 +-- 2 files changed, 25 insertions(+), 70 deletions(-) --- linux-2.6.23-rc1-mm1/fs/Kconfig.old 2007-07-28 23:12:19.0 +0200 +++ linux-2.6.23-rc1-mm1/fs/Kconfig 2007-07-28 23:17:33.0 +0200 @@ -40,16 +40,10 @@ config EXT2_FS_POSIX_ACL If you don't know what Access Control Lists are, say N config EXT2_FS_SECURITY - bool Ext2 Security Labels - depends on EXT2_FS_XATTR - help - Security labels support alternative access control models - implemented by security modules like SELinux. This option - enables an extended attribute handler for file security - labels in the ext2 filesystem. - - If you are not using a security module that requires using - extended attributes for file security labels, say N. + bool + depends on EXT2_FS SECURITY_SELINUX + select EXT2_FS_XATTR + default y config EXT2_FS_XIP bool Ext2 execute in place support @@ -125,16 +119,10 @@ config EXT3_FS_POSIX_ACL If you don't know what Access Control Lists are, say N config EXT3_FS_SECURITY - bool Ext3 Security Labels - depends on EXT3_FS_XATTR - help - Security labels support alternative access control models - implemented by security modules like SELinux. This option - enables an extended attribute handler for file security - labels in the ext3 filesystem. - - If you are not using a security module that requires using - extended attributes for file security labels, say N. + bool + depends on EXT3_FS SECURITY_SELINUX + select EXT3_FS_XATTR + default y config EXT4DEV_FS tristate Ext4dev/ext4 extended fs support development (EXPERIMENTAL) @@ -190,16 +178,10 @@ config EXT4DEV_FS_POSIX_ACL If you don't know what Access Control Lists are, say N config EXT4DEV_FS_SECURITY - bool Ext4dev Security Labels - depends on EXT4DEV_FS_XATTR - help - Security labels support alternative access control models - implemented by security modules like SELinux. This option - enables an extended attribute handler for file security - labels in the ext4dev/ext4 filesystem. - - If you are not using a security module that requires using - extended attributes for file security labels, say N. + bool + depends on EXT4DEV_FS SECURITY_SELINUX + select EXT4DEV_FS_XATTR + default y config JBD tristate @@ -349,16 +331,10 @@ config REISERFS_FS_POSIX_ACL If you don't know what Access Control Lists are, say N config REISERFS_FS_SECURITY - bool ReiserFS Security Labels - depends on REISERFS_FS_XATTR - help - Security labels support alternative access control models - implemented by security modules like SELinux. This option - enables an extended attribute handler for file security - labels in the ReiserFS filesystem. - - If you are not using a security module that requires using - extended attributes for file security labels, say N. + bool + depends on REISERFS_FS SECURITY_SELINUX + select REISERFS_FS_XATTR + default y config JFS_FS tristate JFS filesystem support @@ -383,16 +359,9 @@ config JFS_POSIX_ACL If you don't know what Access Control Lists are, say N config JFS_SECURITY - bool JFS Security Labels - depends on JFS_FS - help - Security labels support alternative access control models - implemented by security modules like SELinux. This option - enables an extended attribute handler for file security - labels in the jfs filesystem. - - If you are not using a security module that requires using - extended attributes for file security labels, say N. + bool + depends on JFS_FS SECURITY_SELINUX + default y config JFS_DEBUG
[patch] i_version mount option
hi,
This patch apply on the top of the ext4 git tree.
It adds a mount option to enable i_version feature for ext4.
Signed-off-by: Jean noel Cordenner [EMAIL PROTECTED]
Index: linux-2.6.22-ext4/fs/ext4/super.c
===
--- linux-2.6.22-ext4.orig/fs/ext4/super.c 2007-07-26 10:48:52.0 +0200
+++ linux-2.6.22-ext4/fs/ext4/super.c 2007-07-26 17:29:44.0 +0200
@@ -736,7 +736,7 @@
Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
Opt_jqfmt_vfsold, Opt_jqfmt_vfsv0, Opt_quota, Opt_noquota,
Opt_ignore, Opt_barrier, Opt_err, Opt_resize, Opt_usrquota,
- Opt_grpquota, Opt_extents, Opt_noextents,
+ Opt_grpquota, Opt_extents, Opt_noextents, Opt_i_version,
Opt_delayed_alloc, Opt_nodelayed_alloc,
};
@@ -793,6 +793,7 @@
{Opt_noextents, noextents},
{Opt_delayed_alloc, delalloc},
{Opt_nodelayed_alloc, nodelalloc},
+ {Opt_i_version, i_version},
{Opt_err, NULL},
{Opt_resize, resize},
};
@@ -1144,6 +1145,9 @@
case Opt_noextents:
clear_opt (sbi-s_mount_opt, EXTENTS);
break;
+ case Opt_i_version:
+ clear_opt (sbi-s_mount_opt, I_VERSION);
+ break;
default:
printk (KERN_ERR
EXT4-fs: Unrecognized mount option \%s\
Index: linux-2.6.22-ext4/include/linux/ext4_fs.h
===
--- linux-2.6.22-ext4.orig/include/linux/ext4_fs.h 2007-07-26 10:48:52.0 +0200
+++ linux-2.6.22-ext4/include/linux/ext4_fs.h 2007-07-26 10:51:11.0 +0200
@@ -489,6 +489,7 @@
#define EXT4_MOUNT_JOURNAL_CHECKSUM 0x80 /* Journal checksums */
#define EXT4_MOUNT_JOURNAL_ASYNC_COMMIT 0x100 /* Journal Async Commit */
#define EXT4_MOUNT_DELAYED_ALLOC 0x200/* Delayed allocation support*/
+#define EXT4_MOUNT_I_VERSION 0x400/* i_version support */
/* Compatibility, for having both ext2_fs.h and ext4_fs.h included at once */
#ifndef _LINUX_EXT2_FS_H
Index: linux-2.6.22-ext4/fs/ext4/inode.c
===
--- linux-2.6.22-ext4.orig/fs/ext4/inode.c 2007-07-26 10:48:52.0 +0200
+++ linux-2.6.22-ext4/fs/ext4/inode.c 2007-07-30 16:08:19.0 +0200
@@ -3107,7 +3107,9 @@
{
int err = 0;
- inode-i_version++;
+ if (test_opt(inode-i_sb, I_VERSION))
+ inode-i_version++;
+
/* the do_update_inode consumes one bh-b_count */
get_bh(iloc-bh);
Re: [RFC] basic delayed allocation in VFS
On Sun, 2007-07-29 at 20:24 +0100, Christoph Hellwig wrote: On Sun, Jul 29, 2007 at 11:30:36AM -0600, Andreas Dilger wrote: Sigh, we HAVE a patch that was only adding delalloc to ext4, but it was rejected because that functionality should go into the VFS. Since the performance improvement of delalloc is quite large, we'd like to get this into the kernel one way or another. Can we make a decision if the ext4-specific delalloc is acceptable? I'm a big proponent of having proper common delalloc code, but the one proposed here is not generic for the existing filesystem using delalloc. To be fair, what Alex have so far is probably good enough for ext2/3 delayed allocation. It's still on my todo list to revamp the xfs code to get rid of some of the existing mess and make it useable genericly. If the ext4 users are fine with the end result we could move to generic code. Are you okay with having a ext4 delayed allocation implementation (i.e. moving the code proposed in this thread to fs/ext4) first? Then later when you come up with a generic delayed allocation for both ext4 and xfs we could make use of that generic implementation. Is that a acceptable approach? Andrew, what do you think? Regards, Mingming - 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
